I spent 5 years trying to get a micro ISV off the ground which made scheduling software for hair salons. It was a terrible idea for a large number of reasons (described in detail here: https://www.jasonswett.net/im-shutting-down-snip-heres-why/) and I never made more than about $430/mo.
My opinion now is that info products are a better way for a solo founder to get started with a product business. The reason is that a SaaS product can take a huge amount of effort (perhaps pre-traction effort, which is risky) to get off the ground whereas an info product business can be started with a tiny "guide" and then expanded outwardly from there, keeping effort in proportion with traction the whole time.
My current business is AngularOnRails.com, an info product business. In its third month of making money, it made $1580, over 3 times what the SaaS made at its peak. Here's a detailed income report: https://www.jasonswett.net/november-2016-angular-on-rails-in...
The harder part about running a solo SaaS company is building revenue takes _a very long time_, particularly if you're new at this. Most of my peers take ~18 months to hit the ~$10k revenue number that lets them durably transition to running the business as the full-time gig.
If you want to run a one-person shop which creates value substantially related to software, but you don't want to bite off the complexity of writing and selling a SaaS app for your first rodeo, I'd recommend a business model like productized consulting (the glide path to shipping a SaaS app!), selling infoproducts, or selling some sort of addon to an existing software ecosystem (WordPress, Shopify, etc).
I tried finding a partner to work with, but that's pretty much impossible in Silicon Valley where I live. Most good engineers want to work for one of the glamorous companies in the Valley. Oh well...
I've been working on Jollyturns for the past 5 years. It's been a lot of work, but I do it at my own pace since I still want to enjoy myself. The experience is unique. I write all the software myself, and hired few people to help map the ski resorts. I built a bunch of custom tools for the mapping work, so people can map the location of lifts, ski runs, restaurants inside a ski resort. I ended up having mapped all the ski resorts in the world, about 2700 of them.
Writing the code is the easy part. I found marketing to be the hardest. You need to find a way to make the world know what you built, and that's hard!
For example, do research that shows that 7% of companies in industry XYZ use certain CRM. Analyze that industry and see what common use cases and pain points are. Somehow figure out what the CRM is missing for that industry. Validate the idea before building it by reaching out to said companies.
There would be a lot more to it, but basically a plugin for established software a company already uses is much easier and less risk to sell when you are a small shop.
Just build something that you know people need (meaning: there are other products in that space) that has a small enough scope so a single person can build it in a month or two. Then charge money for it.
The software market is ludicrously large, and because you don't have marginal costs in a software business you can afford to make a lot of mistakes on the business side of things and still make a profit.
You don't need a great product (plenty of lousy products sell well) and you don't need great business sense (many CEOs don't know what they're doing) and you don't need great marketing (same). For your business to work you have to clear the minimum bar in all three areas, but luckily the bar is set pretty low!
The two biggest things that make this possible:
a) Email support only, no telephone support (sales or post sales). Not everyone likes it, of course, but if you're determined to be a one man band, it's essential.
b) Automation of every single thing you can. For you, it would be a different list, but I had to automate things like refunds, tracking numbers, inventory levels, fraud detection, etc.
Also consider having someone you trust have access to documentation, passwords, accounts, etc...in case of some kind of emergency, etc. If it's making money, it would be a shame not to be able to pass it on to a beneficiary if you were to die unexpectedly.
I ran an advertising agency with employees at one point and grew it to $50k/mo but hated it so stopped and went back to single founder SaaS stuff.
Before the recession hit, I also ran a SaaS product in the Real Estate sector that brought in over $70k/mo at its height. I had a few employees during that time too.
I personally enjoy being a single founder running niche products but it has its downsides. Also, once you reach a certain growth point, it becomes much more difficult to go it alone. At that point, you can either hire employees to help or decide maybe it is best to sell.
Source: I read about Balsamiq Mockups soon after it was created, used it in some commercial projects as a consultant/freelancer, corresponded some with Peldi, and also got a free copy of Mockups early on, for having released an open source product. He had a scheme of giving a free copy to such people. May still have it.
IIRC, he initially had the idea of doing Mockups as a web app plugin (for JIRA, maybe), and did it, but a lot of people asked for a desktop app, so he did that too, and I remember reading that at least in the early years (maybe now too), the desktop app sold much more. I used the desktop app in my work I mentioned.
It's possible, but here's what I have found:
- Partner with resellers who take a commission on sales -- then they can deal with all of the customer management.
- Set realistic goals for uptime, machines go down (it's not if but when), distributed setups are possible and encouraged for larger customers, but they cost more.
p.s. Wanna get a slack channel for solo founders going?
EDIT: I've created a slack group - Email me if you would like an invite!
He builds plugins for the Shopify platform and ended up hiring one developer to do full time onboarding of new clients, support and documentation, but does all product development himself.
I think it's definitely realistic. You gotta just have a mindset where you try and eliminate all bottlenecks and automate as much as possible.
The trick he found for coming up with product ideas was to first do custom development. When enough clients are willing to spend a few thousand for a personal implementation of something, that's when you know you have an opportunity to charge 40$ per month for a SaaS version :)
I went to the conferences when I was a one man startup, and it was helpful.
It's not easy though. Assuming you have product/market fit (i.e. something that sells):
Reliability is paramount. It is everything to you. If your system breaks, it will stop new development, marketing, support responses, sales calls. Because there is only one of you, you can't afford to spend time fighting fires and answering pages. It does not matter if your software is slow or fast or if it is pretty or ugly or if your userbase is growing or not if you are down.
Reliability is paramount. Invest your time into building systems that do not fail when one component or one machine breaks. Where you can, you should leverage primitives and services from cloud providers that provide the kind of failure guarantees you need. Then assume that your cloud providers will eventually fail on you, so design with that in mind. Take as few dependencies on them as you can handle or make sure you can failover between them.
Reliability is paramount. Every change you deploy could break your systems and cause downtime. You need good testing and monitoring. Run continuous end-to-end testing of all customer-facing functionality that pages you when it fails.
Reliability is a feature if your software is critical to your customer's business. Some will notice when your competitors are down and you aren't. For those that don't notice, educate them. Explain to your customers the investments you've made to keep your service up and running. You can sell it as a differentiator.
After that, support is the next time-sink you need to eliminate. Treat every support request as a bug that can be fixed so it doesn't happen again. Make it extraordinarily easy to contact you and then try to optimize so no one ever contacts you. Invest in your UX. Your UX should try to illuminate the inner workings of your software. Many support requests are simply failures of a customer to understand what your software is doing and why. Customers can't debug black boxes, but they are smart and motivated and if you invest in their understanding, many will solve their own problems before contacting you.
Design your error messages. Your error messages are a more important piece of design than any other messaging from your product. Finally, if you can't solve the support bug with UX, invest in your documentation. Documentation is your last resort because most users will not read it or they will only read portions of it. By the time they get to the docs they're already frustrated, so it needs to be fantastic.
It appears to working out quite well for him, as he is currently on holiday overseas.
I have a full time job but one client on the side. I built a system for them that I net $1,250 per month on and do 2 hours of work a month at most. Rackspace takes care of almost all host related items for me.
I have a partner who also makes $1,250 from the same contract. In hind sight I could have easily done the whole project without him and be making $2,500 per month.
Been going for almost 3 years now, probably has a shelf life of another 7 years.
If you can get a few customers like this, you are set. The challenge is of course to get more customers, let me know when you solve that issue, I'm still working on it :)
edit: changed gross to net
I know a guy who continues to run a one-man software shop for some municipal government functions that are important, but too small for a more general software company.
Key factor for him is that his uncle had been a well-known person, which got him in the door early on.
Too many pay apps and even games with DLC have gone poof in recent years because of the latter situation or because the cost of maintaining the DLC no longer justified itself.
Eventually, either due to growth or a desire to have free time again, you'll probably want to bring aboard other persons.
No other data source is capable of providing the content we needed. We were forced to shut down.
We knew this was a possible eventuality and our ToS explicitly disclaimed responsibility for it. Our site required users to check both a checkbox and click OK on a dialog box that served only to inform that they used the product at their own risk, nothing was guaranteed, and no refunds of any kind would be furnished. When we shut down, many angry users demanded refunds and issued chargebacks, often after months of successful use, despite the clear and unambiguous language which confronted them several times and required their affirmative assent before they were allowed to purchase anything.
Before we were forced to shut down, other people had caught on to the market and started copying us. We had about a year where we were in it by ourselves. Once serious competitors showed up, they ate our lunch by using a sophisticated spam network to promote their offerings, which were sloppily made by offshore contractors and far worse than our offering in every way, technical and aesthetic.
I refused to engage in similar tactics and felt righteous about it, but it sure cost us a lot of money. They somehow brokered deals with the niche forums that had blacklisted us from day one (or just outspammed their moderation capacity), afraid that we may eventually expand into something that would threaten them directly (which I now plan to do, some day). Perhaps we could've prevented the copycats by acquiring software patents.
These competitors pushed the envelope to the point where it became a visible PR issue and the F100 was forced to respond by C&D'ing every site that operated in the sector I launched and instructing their users to never use anything not distributed directly by the company itself again.
Now, about 16 months post-shutdown, I still get emails from business owners who depended on us begging me to turn the service back on, and saying that their business has been seriously hurt by our absence.
Some of the people in this thread evidently picked much better niches than I did.
I'm ok on the sysadmin side (backups, Ansible, etc) and uptime. I'm subpaar on the support side, because I can't develop features fast enough and I have a problems prioritizing things that my various customers need and, at the same time, I panic at the idea of telling them that "I don't know" whether I'll deliver their tiny feature in 1 week or in 8 months. Anyway, it's all problems you can solve by being more efficient or professional, just keep in mind that support/bugfixing will creep up as you add features, up to 80% of your time, at which point you'll either have enough money to hire, or notice that the business model doesn't bring enough money.
There is definitely room for us, micro ISV: Do it as long as you like it / enjoy the lifestyle.
Also, "don't talk to corp dev" (cf Paul Graham's essay) unless you want to sell, in which case use an acquisition broker marketplace (cf patio11's essays).
The problem you may face, is you will need to know how to program in a 'production' environment. So were as in academia you can be a single person running code, in industry, you will have multiple people utilise and check your code. It will have to be robust and scalable. So you may need to brush up on programming skills, though you could be great from the start.
Something I've seen with Academics, is that whilst they are great at solving detailed problems, they sometimes fail to present the impact of their work in a business context, or what they can offer and how it solves business problems, rather than just "interesting" problems.
My advice would be to apply and see what comes back, and get feedback from the people you apply to.
I recently demonstrated a really simple bagged-decision tree model that "predicts" if the scanned part will go on to fail at downstream testing with ~95% certainty. I honestly don't have a whole lot of background in the realm of ML so it's entirely possible that I'm one of those dreaded types that are applying principles without full understanding of them (and yes I do actually feel quite guilty about it).
The results speak for themselves though - $1M/year scrap cost avoided (if the model is approved for production use) in just being able to tell earlier in the line when something has gone wrong. That's on one product, in one factory, in one company that has over 100 factories world-wide.
The experience has prompted me to go back to school to learn this stuff more formally. There is immense value to be found (or rather, waste to be avoided) using ML in complex manufacturing/supply-chain environments.
One of the products the company I work for sells more or less attempts to find duplicate entries in a large, unclean data set with "machine learning."
The value added isn't in the use of ML techniques itself, it's in the hype train that fills the Valley these days: our customers see "Data Science product" and don't get that it's really basic predictive analytics under the hood. I'm not sure the product would actually sell as well as it does without that labeling.
To clarify: the company I work for actually uses ML. I actually work on the data science team at my company. My opinion is that we don't actually need to do these things, as our products are possible to create without the sophistication of even the basic techniques, but that battle was lost before I joined.
We use ML/Deep Learning for customer to product recommendations and product to product recommendations. For years we used only algorithms based on basic statistics but we've found places where the machine learned models out perform the simpler models.
Here is our blog post and related GitHub repo:https://aws.amazon.com/blogs/big-data/generating-recommendat...https://github.com/amznlabs/amazon-dsstne
If you are interested in this space, we're always hiring. Shoot me an email ($email@example.com) or visit https://www.amazon.jobs/en/teams/personalization-and-recomme...
In our space, the recent AI / ML advances have made things possible that were simply not realistic before.
That being said, the hype around Deep Learning is getting pretty bad. Several of our competitors have gone out of business (even though they were using the magic of Deep Learning). For example, JustVisual went under a couple of months ago ($20M+ raised) and Slyce ($50M+ raised) is apparently being sold for pennies on the dollar later this month.
Yes, Deep Learning has made some very fundamental advances, but that doesn't mean it's going to make money just as magically!
1. Course Recommendations. We use low rank matrix factorization approaches to do recommendations, and are also looking into integrating other information sources (such as your career goals).
2. Search. Results are relevance ranked based on a variety of signals from popularity to learner preferences.
3. Learning. There's a lot of untapped potential here. We have done some research into peer grading de-biasing  and worked with folks at Stanford on studying how people learn to code .
We recently co-organized a NIPS workshop on ML for Education: http://ml4ed.cc . There's untapped potential in using ML to improve education.
The primary advantage for customer is easier to use and troubleshoot faster.
One way we're applying this is automatic creation of panoramic tours. Real estate is a big market for us, and a key differentiator of our product is the ability to create a tour of a home that will play automatically as either a slideshow or a 3D fly-through. The problem is, creating these tours manually takes time, as it requires navigating a 3D model to find the best views of each room. We know these tours add significant value when selling a home, but many of our customers don't have the time to create them. In our research lab we're using deep learning to create tours automatically by identifying different rooms of the house and what views of them tend to be appealing. We are drawing from a training set of roughly a million user-generated views from manually created guided tours, a decent portion of which are labelled with room type.
It's less far along, but we're also looking at semantic segmentation for 3D geometry estimation, deep learning for improved depth data quality, and other applications of deep learning to 3D data. Our customers have scanned about 370,000 buildings, which works out to around 300 million RGBD images of real places.
The same coworker also used decision trees to analyze query performance. He trained a decision tree on the words contained in the raw SQL query and the query plan. Anyone could then read the decision tree to understand what properties of a query made that query slow. There's been times we're we've noticed some queries having odd behavior going on, such as some queries having unusually high planning time. When something like this happens, we are able to train a decision tree based on the odd behavior we've noticed. We can then read the decision tree to see what queries have the weird behavior.
We work with B2B and B2C SAAS, mobile apps and games, and e-commerce. For each of them, it is a generalized solution customized to allow them to know which end users are most at risk of churning. The amount of time range varies depending on their customer lifecycles, but for longest lifecycles we can, with high precision, predict churn more than 6 months ahead of actual attrition.
Even more important than "who is at risk?" is "why are they at risk?". To answer this we highlight patterns and sets of behavior that are positively and negatively associated with churn, so that our customers have a reason to reach out, and are armed with specific behaviors they want to encourage, discourage, or modify.
This enables our customers to try to save their accounts / users. This can work through a variety of means, campaigns being the most common. For our B2B customers, the account managers have high confidence about whom they need to contact and why.
All of this includes regular model retraining, to take into account new user events and behaviors, new product updates, etc. We are confident in our solution and offer our customers a free trial to allow us to prove ourselves.
I can't share details, but we just signed our biggest contract yet, as of this morning. :)
For more http://appuri.com/
A recent whitepaper "Predicting User Churn with Machine Learning" http://resources.appuri.com/predicting_user_churn_ml/
Generally speaking, I think if you know your data relationships you don't need ML. If you don't, it can be especially useful.
We use "real" ML for sentiment classification, as well as some of our natural language processing and opinion mining tools. However, most of the value comes from simple statistical analysis/probabilities/ratios, as other commenters mentioned. The ML is really important for determining that a certain customer was angry in a feedback comment, but less important in highlighting trending topics over time, for example.
Not really a new application though...
On the other hand I found an internal fraud costing us 2-3 M /year applying only the weak law of big numbers. Big corp, big numbers.
Now I build a similar system for a smaller company. I think we will stick mainly to logistic regression. I actually use "neural networks" with hand-crafted hidden layers to identify buying patterns in our grocery store shopping cart data. It works pretty well from a statistical point of view but it is still a gimmick used to acquire new b2b partners.
We use neural nets to generate descriptors of videos where motion is observed, and classify events as normal/abnormal.
We also use ML to classify bittorrent filenames into media categories, but it's pretty trivial and frankly the initial heuristics applied to clean the data do more of the work than the ML achieves.
We also support linear regression in the product itself - it was actually an on-boarding project for one of the engineers who joined this year, and he wrote a blog post to show them off: https://www.periscopedata.com/blog/movie-trendlines.html About 1/3rd of our customers are using trendlines, which is pretty good, but we haven't gotten enough requests for more complex ML algorithms to warrant focusing feature development there yet.
There are a number of other statistical techniques you can use for this but scikit-learn makes this very very easy to do.
I would classify something like this blog post as ML, would you? http://stackoverflow.blog/2016/11/How-Do-Developers-in-New-Y...
Trad learning for many applicatons : fault detection, risk management for installations, job allocation, incident detection (early warning of big things), content recommendation, media purchase advice, others....
Probabilistic learning for inventory repair - but this is not yet to impact, the results are great but the advice has not yet been ratified and productionised.
The bulk of what we do is anomaly detection.
 https://skymind.io/case-studies insights.ubuntu.com/2016/04/25/making-deep-learning-accessible-on-openstack/
The first pass is usually a regex to find names, then for what's left run a natural language tool to find candidate names, and then manual entry.
Marketers create their messages and define their goals (e.g., purchasing a product, using an app) and it learns what and when to message customers to drive them towards those goals. Basically, it turns marketing drip campaigns into a game and learns how to win it :)
We're seeing some pretty get results so far in our private beta (e.g., more goals reached, fewer emails sent), and excited to launch into public beta later this month.
For more info, check out https://www.optimail.io or read our Strong blog post at http://www.strong.io/blog/optimail-email-marketing-artificia....
Also, some GPU goodness for 10-100X visual scale, and now we're working on investigation automation on top :)
(We're still beginners as will be apparent from the video but it's proving useful so far. I should note, we do have 'proper' data scientists too, but they are mostly working on audience analysis/personalisation).
Wrote a system for automatically grading kids' essays (think the lame "summarize this passage"-type passages on standardized tests). In that case it was actually a platform for machine learning - ie, plumb together feature modules into modeling modules and compare output model results.
(www.queckt.com is anyone's interested)
Without AI/ML, we wouldn't have a product.
Aka e-discovery : produce digital documents in legal proceedings.
What was special: stringent requirements on statistical robustness! (the opposing party can challenge your process in court -- everything about way you build your datasets or measure the production recall the has to be absolutely bullet proof)
IT & SECURITY
Anomaly detection in system usage patterns (with features like process load, frequency, volume) using NNs.
What was special: extra features from document content (type of document being accessed, topic modeling, classification).
Built tiered IAB classification  for magazine and newspaper articles.
Built a topic modeling system to automatically discover themes in large document collections (articles, tweets), to replace manual taxonomies and tagging, for consistent KPI tracking.
What was special: massive data volumes, real-time processing.
Built a recommendation engine that automatically assembles newsletters, and learns user preferences from their feedback (newsletter clicks), using multi-arm bandits.
What was special: exploration / exploitation tradeoff from implicit and explicit feedback. Topic modeling to get relevant features.
Built a search engine (which is called "discovery" in this industry), based on Elasticsearch.
What was special: we added a special plugin for "related article" recommendations, based on semantic analysis on article content (LDA, LSI).
HUMAN RESOURCES (HR)
Advised on an engine to automatically match CVs to job descriptions.
Built an ML engine to automatically route incoming job positions to hierarchy of some 1,000 pre-defined job categories.
Built a system to automatically extract structured information from (barely structured) CV PDFs.
Built a ML system to build "user profiles" from enterprise data (logs, wikis), then automatically match incoming help requests in plain text to domain experts.
What was special: Used bayesian inference to handle knowledge uncertainty and combine information from multiple sources.
Built a system to extract structured fixtures and cargoes from unstructured provider data (emails, attachments).
What was special: deep learning architecture on character level, to handle the massive amount of noise and variance.
Built a system to automatically navigate banking sites for US banks, and scrape them on behalf of the user, using their provided username/password/MFA.
What was special: PITA of headless browsing. The ML part of identifying forms, pages and transactions was comparatively straightforward.
... and a bunch of others :)
Overall, in all cases, lots of tinkering and careful analysis to build something that actually works, as each industry is different and needs lots of SME. The dream of a "turn-key general-purpose ML" is still ways off, recent AI hype notwithstanding.
Adding sockets for, say, the 3 newest logs they get in real time. Or if they have anything that maps to a graph/app-overview just make sure that will always update in real time. It's not a huge time investment for me. Customers usually never request it specifically. But I've found they are blown away when they see how everything is updated in real time. It just makes the whole thing feel 'alive'.
Another thing which I don't personally love, but I do because I understand industries have differences is just exporting whatever can be exported into .csv files or .xls files where applicable.
All in all, I work in consulting. The code I write is meant to make the life of people easier, I want to make sure they get that when possible. A big part of why I'm able to do this is that I have a lot of creative freedom to do whatever I want so long as I'm getting stuff shipped. So huzzah for comprehensive management as well!
So, back in 1994, my dad and me started an ecommerce company (bikeworld.com) that sold bicycle parts online. It was an extension of his brick-and-mortar bicycle business and I took a couple of years leave from college to help him build it.
He did one thing early on that generated amazing word-of-mouth support: send a little treat in every order box. Our company was based in San Antonio, TX and Dad decided to include a little local flavor with each order to make us stand out from the few competitors we had back then (incumbent mail order outfits). At every good Mexican restaurant back home, they sell Mexican chewy candies at the cash register when you pay after your meal. My dad and I loved these things so he went to the manufacturer in town and bought a few cases of them. They were really expensive, like $0.50 each, and it became a big expense but the customers went nuts. Dad printed up a little card that he put in the bag with the candy, explaining the tradition and thanking them for their business. It worked well--we quickly became one of the largest online bicycle stores of the late 90s.
Most educational, and it has resulted in a number of improvements to our product line (subsea handling equipment - used for deployment and maintenance of subsea wellheads, submarine communication&power cables, &c, &c.)
They all expect you to ask what feature they like best; they're always baffled when you rather ask where we've screwed up - and more than happy to help! :)
This is very cheap and effective market research.
I run The Human Utility (formerly the Detroit Water Project) and we help folks with their water bills. When they reach us, they're used to dealing with other social service agencies that aren't very responsive and don't do something as basic as ever calling them back. We do and we find that people are grateful even for that.
Edit: People are happy to hear from us regardless of whether we actually help with their bills. If we say we can't, at least they know to try elsewhere and can do so fairly quickly.
I did a few jobs where someone else controlled the billing, and kept us on a tight schedule. Every hour was billed. We were "fired" (AKA contract not renewed) every time. Yet when I went above and beyond, I had no problem getting and maintaining awesome clients.
As someone on the opposite side now (hiring freelancers), I've realized the thing I value most: the freelancer gives me less work, not more. It may seem obvious, but when I was on the other side, it wasn't. When I hire freelancers now, I value one overarching quality: to make my life easier. I don't care about price or hours (within reason), I care about not having to think about it.
It's pretty cool to get a handful of emails every day from actual customers who are very grateful for the work we do.
It also changed my opinion on the "canned CEO greeting". As someone who knows how those are built, they always struck me as annoying and disingenuous sales gimmicks, but our customers are significantly less tech savvy, and a huge number take the correspondence at face value and actually start a real conversation with the CEO.
Specifically, I have a skeleton requirements document that I put together from our previous correspondence (there's always a phone call, few emails, etc.) trying to flesh out their project needs. It doesn't matter if this is incomplete, inaccurate, or any other in-word. It shows that I'm a professional who has tried to understand the problem, the business case, possible solutions, will approach it methodically and like a real engineer, and that I know what I'm doing.
Those 10-15, printed, very real, pages, mostly just ?-marks, have written me more contracts than I can count. It takes about 1-2 hours of work to write things up, but I've never - not once -, had a potential client fail to notice and be impressed when I show up and have a presentable document already underway.
Apparently this is unusual. I can't imagine doing it any other way; I mean, who wants to deal with thousands of emails from customers who are owed account credits?
Almost always I find money being drained away. There was the time when a company targeting Python developers was losing its AdWords budget on snake enthusiasts. Another time a mobile analytics company was spending thousands on people searching for free apps. In another case a company whose ads went to a 404 page and nobody realized. Also recently I found that an SEO agency was falsifying results to one of my clients (the contract was quickly terminated).
I don't know if "blown away" is the correct phrase. It's more like a brief moment of embarrassment followed a huge sense of relief that a budget leak was found and plugged.
PS - The companies described here have successful products made by brilliant people. This is more a symptom of hiring the marketers who don't have the skill (or intention) to demonstrate the results of their efforts.
I occasionally bump into old customers and many still run the same server. All of them are today using revision control systems.
So basically we didn't just provide a tech solution, but also brought in methodology and free tools to implement that methodology.
I have a rotating list of power user tips. I'll pick one to show someone during a trouble call (provided no one is in a huge hurry). It has to be something cool that I can demonstrate/teach in seconds. Examples:
Snipping tool. Rather than writing down error codes.
Windows key + start typing the program name. Rather than navigating the start menu.
Piles of excel tricks. (everyone loves excel)
The big thing is knowing your audience. People enjoy participating in something, not just being shown things they can never accomplish. If you make it something they can't understand it will just make them feel stupid or frustrated.
That mirrors my experience when I was on the service provider side, and as someone who is now consuming those same services, I can confirm that I am most impressed by my providers when the communications are focused, helpful and timely.
A lot of the time, when a client has a request, they are thinking out loud in the moment.Even if I can't pick up the phone, I'll send a short email straight away to let them know that
1. I got the message 2. Timeframe when I can action
We did this on one education site we developed, and also gave them the ability to choose from about a dozen 'stock' cartoon style avatars if they didn't want to upload their own images. The users were impressed at the handover training session we ran, but I overhead one guy (who was indigenous Australian aboriginal descent) jokingly remark that the stock avatars didn't have a person of indigenous culture represented.
I took note of that, and when I returned to the office, we added a handful of indigenous avatars as well within the hour. Client was happy that we went the extra mile to take their offhand comment seriously and deliver on it.
2. Saying 'No' to 'easy money' projects. We've worked with some of our clients for over 20 years now. Mainly because often when they come to us to add on features to their custom written apps, we often say 'No', along with some valid data to explain why we thing the $$$ sunk into the added feature are of very little benefit.
This has lead to them trusting us a LOT more when we go the other way. Real world case study - we had one client, whom we developed a short term loan application for, ask us to add a Monday morning report with customer mobile numbers so they could do a ring around check for customers who were about to default on their loans.
I said 'Sure, but lets go one better'. I said that along with the report, it wouldn't take much extra work to actually have the system send out an SMS message to all those clients as well, with details on their upcoming defaults, and what they needed to do to fix the issue.
They were delighted and said to go for it. Well, that was two years ago, and it turns out that the SMS messages by themselves have reduced their default rate by an incredible amount, and they are FAR more profitable as a result. Hmm, maybe I should have asked for a percentage of profit increase as my payment! :)
Get an easier Excel sheet containing data. They're gaga about that. I've won contracts just by showing them that they will get all the data in an Excel sheet.
Every single lead I've talked out of working with me, has referred me to another customer and/or came back weeks-years later with a bigger project that did make sense to pursue.
Choice quote: are you allergic to money?
- I offer them more than what they expect. At times scraping additional info which I think is useful but they did not realize I extract that too. Sometimes they ask for the script or data, one of them and I just offer them both and they appreciate it lot. Though that script is not helpful for them and they eventually come to me but it's just increase their trust.
- It sounds silly and dangerous but often I don't ask advanced payment from clients and prefer to show off some skills, mostly it was quite helpful and they worked me on other projects as well.
But because I pick up the phone when they call and I seem trustworthy, they pay it. Also, I take my work very seriously, and they get what they pay for.
Contrary to what I read here, I put me first, my company second and the client third. I think that in consulting, this is the only way to stay sane and deliver on time and to spec.
I don't work in the IT department and they basically say no to everything. Regardless of business value or difficulty.
I work in the chief executive office and numerous departments will be amazed when I say yes... Let me look into that.
Recent example was a publicly facing, real-time waiting time tracker for the city's A&E (as well as two walk in centres). Each solution I thought of had compromises but they chose the one they could live with.
- I bring homemade cookies to our first meeting and if the client likes them, to subsequent meetings. The first time I did this for purely selfish reasons; I like cookies but I'll eat the whole batch myself unless I get someone else to "take a cholesterol bullet" for me.
- I'm extremely honest and forthcoming. I tell them that it may sound like I'm trying to talk them out of hiring me but what I'm actually trying to do is make sure we're a really good fit. I tell them even the non-flattering data about my capablities or lack thereof i.e. I've told more then one potential client "I can spell 'SQL'" when they tell me they'd like to incorporate a data base in the product they want me to make. (But my wife is an expert and she'll help me out.) I tell them my estimates are usually off by a factor of 4X. You know what is worse than not getting a contract? Getting a contract where you can't make the client happy.
- I tell them that they can probably do the job without me - and I mean it. "Here's how I would do this. ... That part might be tricky, I can't remember off the top of my head but I'll look it up and send you some links on this.. Buy me lunch and you can pick my brains."
- Communicate even when there is no news or it's bad news. "I still haven't received your hardware but I wanted to call so you'd know before you left for the weekend. I'll call the vendor on Monday."
Lots of them will ask why a certain decision was made that seemed unusual, and sometimes the dialogue gets into some rather detailed nuances of how readers interpret bits of information and how it's delivered. I came to resume writing after ~20 years in recruiting, so I am able to provide insight into what the audience for their resume is thinking.
Clients say they like the collaborative approach and appreciate that they learn things that they can apply next time (and not have to pay for the service again).
Don't roll your eyes. You might live in a JS filter bubble but there are a lot of impoverished developers working in software engineering ghettos.
To me it really is as simple as don't be a dick.
I also offer something that I find most web people don't: I offer them good customer service. I answer my emails within 24 hours and I pick up my phone usually when they call or I get back to them asap. I try to give them a reasonable price and I expect payment upon delivery of my invoice.
I have just a few clients, but I've never had issues. And most of the time that is what my clients have confirmed that I have offered that no one else offers: customer service. It's just being extremely supportive. They want to know that someone is there when there is a problem. There is nothing worse than the feeling of running a business.. and knowing that you are screwed or worse -- you have to pay someone you don't know a fortune in an emergency situation.
We send cards and/or gifts on Christmas for every client. I and my partner write all the cards. We always thank the client for being with us another year and we ensure them we will do everything possible for the next year to be even better.
We haven't lost a client in the past two years. We have about 30.
1. Make it clear that solving their problem is paramount. Not your policies, not getting off the phone ASAP. Sometimes it's something you can help them with directly with your product, sometimes you can't, but just treating them like a person you want to help instead of someone to hang up on is apparently unusual. (This is also a good fit for a lot of the techie folks on HN.)
2. Send a handwritten note. My handwriting is terrible, practically illegible, but people like that I took the time to write to them with pen & paper. Ironically, I didn't do this for a long time, because I thought it would look cheesy, but I gave it a shot and realized I like the little bit of gratitude it brings into my day-- that's really why I do it.
Somehow, at least for (native?) mobile, the spec to implementation transformation still seems magical to many of our clients. I personally think it's the rapid turn around. It seems there's an expectation still that the development will take longer and thus the reaction?
Here are my top 2:
I have a simple motto: I aim to save my clients money. This can work in lots of different ways, shaving a day off development here or there, coming up with cheaper solutions, even outsourcing little tasks to UpWork or automating them via an existing web service.
#2: At the end of each week, I like to send a quick summary email. I got that tip from another freelancer. Even though clients have access to online project management, it gives them additional reassurance and they go into the weekend with a sense that you're doing good work on their behalf.
People went crazy about the handwritten note and got thank you notes for the note! I think it was so different that it was a cool surprise.
Most of the time they can't believe it either. It's fun.
I'm a sort of internal consultant in my company who often interfaces with external customers. I've repeatedly heard that no one else provides as thorough yet easily understood documentation. They value the results, but value truly understanding them and being able to follow how I got them almost as much.
I also think it's the ability to understand that the business and the technical elements may not always work in lockstep, and being able to translate the needs of one to the other.
1) Keep emails short. I set a 200 word max on all emails. If you can't say what you need to say in 200 words, schedule a meeting to discuss. If you have to send long documents, send a 2-3 sentence summary. Tell them what you're going to tell them, tell them, tell them what you told them... in 200 words. (=
2) Keep detailed time records and make them available to the client on-demand. They paid for it, might as well show them what they are getting. Be honest... if your team wasted 4 hours trying to make sense of a BS email from the client... make sure they understand that.
3) Being on time and inclusive; inviting them to daily standup meetings with the team, and posting notes from those standup meetings in case they (or anyone else) can't be there. Easy with a Google Sheet to just type a few notes each day during standup. I don't have any tools for the team that the client can't access, or hasn't been given a rundown on how we utilize it.
Effective knowledge transfer is another aspect. Not just coding up a solution but teaching others how to solve specific problems by themselves is highly valuable.
This happens ~4 times/year for major releases.
The longer a claims file, the more I get excited because the chance of a VA error is already very high - in a 4,000 pg file I can guarantee at least one big one
I have a big success rate in winning bids. I'm not a sales man, I can help them and a proposal is discussed immediately and i just start
I'll see myself out.
"Programming is one of the most difficult branches of applied mathematics; the poorer mathematicians had better remain pure mathematicians."
- Edsger Dijkstra
The storefront is through ShapeWays and I use ifixit to drive the traffic. It's passively making ~$425/mo with about 10 minutes of work per week on my end. This all happened because my grinder failed and I couldn't get parts.
[Somewhat related: http://www.mrmoneymustache.com/2012/01/13/the-shockingly-sim... ]
Thanks to a complete lack of material in this niche, the site (http://pengapplicant.ca) gets a decent amount of organic search traffic given the niche size (2k page views per month) and I make about $15/month in Adsense. Recently I was also contacted by someone who sells materials for the application and exam and have become an affiliate for them. It's only been one month, but i've already made one referral which netted me $100. So passive income on this after hosting costs is probably $220-ish and will be more in 2017 hopefully with more affiliate sales. Obviously very small potatoes, but I never set out to make any money for this and it looks like now it will at least cover my yearly professional dues ;)
To be honest, the best part is the messages I get from people saying how I helped them get their license. That's a much nicer feeling than the $.
I built a bot network that reads tech events - mostly meetups, some conferences and workshops - for a given city from a variety of sources and tweets them. I use machine learning to determine hashtags, time of day to tweet, and new data sources. When I launched Austin - https://twitter.com/ATXTechEvents - in September 2015, I got 900 followers the first month. I suspected it was a fluke so launched Dallas FW and Houston to test. It wasn't a fluke.
In 2016, I've launched 45 different cities in the US and the network has 100k followers collectively, has its own automated weekly mailing list, and is generating 1.4M+ impressions/month. Revenue is affiliate fees for conferences (we are a media partner for O'Reilly) and workshops and selling the ad blocks in the newsletter. Almost all of that is automated. The revenue is pretty minor right now but growing and I spend 1-2 hours on it a week.
The landing page is here:https://techeventsnetwork.com/ (only some of the cities)and the full list of cities is here:https://twitter.com/TechEventsNet/following
- Rich Dad, Poor Dad got me into the idea of 'passive' income. Nothing is truly passive of course, but it makes me think about what I do
- SourceGuardian. This is encryption software I set up in 2002 as I had a need myself and the nearest product was $6000 at the time. It has generated a great passive income since then. Enough to pay all my bills. 2016 was no different. I work with 2 other people on it, one of whom I've never met (he's in Russia) and it works well
- Competitor Monitor. This used to be a side-project 5 years ago, but it has grown significantly and in the past year we are up by 35% and we have grown our team. Strangely this has now become passive in the sense that I have created a structure and systemised the business (read The Emyth Revisited book) and that has allowed me to step out. I am not more of an investor than a day-to-day contributor
- UKscrap.com. This one died in 2016. The site is still there, but competition and my lack of interest killed it
As I said, nothing is truly passive, but you need to have a passion for whatever you do and I would try to create a 'passive index' for your ideas. How much time will they take to get off the ground, how much to run monthly, what is the product life cycle (if you can work that out!). From when I started there are a HUGE number of resources to help you also. Feel free to ask for help or advice, for what it's worth!
EDIT: I actually met my SourceGuardian partner once in Prague for 2 days. Forgot that when I wrote the above!
But than I found another tab in the utterly shitty admin panel and it hit me like a rock. The numbers on the dashboard were a monthly overview and in fact we earned already hundreds of dollars and downloads in just a few days. I went back to the computer, but together an even better watch face, set it to 1$ again and watched it selling like hotcakes.
However it tried out quite quickly after that. People started to copy stuff and giving it away for free and I never bought the watch myself, I just used the emulator to test my apps. So I took them out of the store at the end because dealing with taxes and sharing the income does not make it worth it if you get support requests like "how can I change the time on my watch", "what do I care, its your shitty watch and Samsung's shitty interface"...So yea. That's my best story about unexpected passive income. Selling stuff fast on a new platform seem to work!
Edit:Found some screens.First one: https://i.imgur.com/TIVsPKO.pngBest selling one: https://i.imgur.com/9L8TetO.png
since tesla is such a controversial company, lots of people want to own the stock (expecting it to go up) and lots of people want to short sell it (expecting it go down).
if you're a stock holder, certain places (like interactive brokers) will let you lend your stock holdings to people that want to sell it short. you earn a premium on this loan, but its basically risk-free since the brokerage bears the counter-party risk.
because short interest is so high, there was a substantial portion of 2016 where there weren't enough shares available to satisfy short sellers' demand. TSLA became classified as "hard to borrow" and borrowing premiums would be anywhere from 8% to 100+% depending on the day/demand. this is money short sellers pay on top of the cost to purchase the shares (and one more thing to bear on top of the risk of short-selling, but that's another story).
the premium is paid daily, and the brokerage usually takes a chunk of it (often half), so if you had $100k of tesla stock and the premium was 50%, you'd earn (100,000 * 50% * (1/2) / 365) = $68.50 for each day that someone borrowed your shares. the rate fluctuated daily, but this still netted me several thousand dollars of truly passive income, since i was planning to hold the stock either way. this is also a huge income stream for institutional shareholders that are sitting on millions of shares.
Made $104,000 in revenue since June (turns out the user acquisition stuff actually works), about 87k of which is profit, so we'll say ~$11,000/month part-time. It still makes me a solid $2,000/month now with zero work, and hopefully more once the book is officially published. (It's done and delivered to backers, but won't be on bookshelves and Amazon until after it's typeset.)
I know the marketing will be over-the-top for HN. Just know it sells because the content is really, really good.
Just checked and this year I've made about $13,000 in profit. It's mostly passive this year I started using a fulfillment company so the majority of my work is sending them orders (and answering questions about the book.)
Hoping to continue the trend next year by launching a book on teaching design for engineers (http://hellowebdesignbook.com).
We started a small online shop about 10 years ago, and it's mostly automated. About 5 minutes/day + one week / year of work.
Before that, I had spent a few years (trying to) run rather big software projects (for me I was 18 or 19). They had cost me so many sleepless nights that I swore to never again take on customers paying me more than 100 Euro each. Now, if anybody complains, or gets on my nerves, they get their money back and are never heard from again.
My friends joke I'm the living example for an unconditional basic income. They haven't decided on the outcome yet, though.
Interestingly it has been very popular with teams (so selling a set of licenses so a whole team of developers can use the material). I also teach the same material in person (either in-house or in open workshops) so I'm keeping the two in sync. I made some notes about that process on my blog: https://rachelandrew.co.uk/archives/2016/06/03/creating-an-e...
I intend to do a bit more marketing of both the in-person and online training in the new year.
As an independent (not working for a browser vendor) invited expert to the CSS Working Group, training and offering this course is really how I can fund doing that.
It's a price comparison website for top-level domains. Gross on average is $600/month through affiliate sales and data download subscriptions. Requires maybe 10-20 hours of work per month for maintenance and new features.
The most difficult part is tracking registrar affiliate earnings, and then actually getting paid by the registrar. Many require you to manually request a payout once you've reached the minimum payout threshold, others simply ignore your payout requests.
It's a tricky product because the way the app work is not for everyone, at the same time when people use it they normally share it with their friends. So I get good organic traffic. The biggest issue is to explain whats unique about this productivity tool, but seeing the video normally do the job.
It's not able to pay for me not working yet as I live in NY so there are obvious reasons for that being hard.
But it does provide me with a healthy chunk of money. And through feedback from customers I have found a new product in the same area and that will be a SaaS product.
Didn't do any work on marketing really so it is pretty much passive, but I think with a bit of work they could both do a lot better. It's a very seasonal market - we only get customers for about 3 months per year (the 3 months leading up to the exams), so thinking of branching out into other exams that occur during other times of the year so the income is a bit more steady.
They are making some nice money each year, but the trend is quite clear: given same traffic I am making about 50% less each year. Ad revenue is way down (more adblock users, less money per click, CTR is down), but paid premium plans are balancing it a bit.
These projects are still my biggest passive income stream, but they are going to die in few years. Other than that I am owning agriculture land (that I am renting), rental property and portfolio of p2p loans.
Those traditional assets are much more expensive to acquire, but then the yield is much predictable and stable. Still, the tech projects are my best source of income considering the amount of money/time required to create it.
I launched it a few months ago and have a few smaller subscribers with a handful of larger subscribers.
Of course, because of my laziness, I took the passiveness too far and it's now all but impossible to reuse it for another potential client.
It was fun while it lasted.
You can go further and buy government bonds directly, through the Tesouro Direto system. Those indexed by the SELIC rate (which is sort of related to the CDI) are currently around 13.5% per year, before administration fees and taxes (in fact, the boring funds I mentioned above mostly invest in these SELIC-indexed government bonds).
This will change when (and if) rates get lower, but so far, investing in these funds or bonds is the simplest (and one of the best) way to have passive income.
I'm now considering doing this again in 2017. Hopefully interest rates will remain as low as they have been in order to lock-in an attractive mortgage.
My friend has made about $650 off of his AMD investment so far though and is thinking of moving all of it into Micron.
Released this week. Came unnoticed on HN but somehow got featured on PH. 1200+ downloads of free version and a few sales.
Not sure if that'll change. In that case, the best of 2016 will be one of the plugins for Sketch https://news.ycombinator.com/item?id=12319286.
Hope to have it really pickup once done and turn profitable
The next guy wasn't good and eventually didn't want to actively manage the account. I kept looking until this year when I found fractalgo, which is used by large institutional investors to trade through science without emotion and second-guessing.
Downside is you needed to be a qualified investor.
I called up the owner curious about how the fractal tech worked and found out he was setting up a service for everyone, not just the big guys.
After some research I moved my IRAs left over from previous 401Ks to a custodian that can do directed investments + broker and let the automated system go.
Couldn't be happier. No humans required once set up, and it keeps growing like a weed while I sleep.
Do your own research for what works for you and seek it out. You will find it, eventually.
Since doing so well, they just opened a fund using the same technology.
p2p lending is hit or miss for me: 3-10%
Index funds pull in the rest.
I've also moved temporarily to a very cheap COL country so that I can focus on some more side projects to pull in extra sources of income before I return to the work force.
It shines when you search for something that you want the best version of, without caring about the details; i.e., let the masses determine the quality for you. It weights results based on ratings, review volume, and some other stuff, segmenting the results by price range.
Helps me answer the question "I want the best phone mount for my bike, but I don't want to spend more than $20" without fiddling with Amazon's search parameters and then scanning the page.
Makes ~$100/month off of affiliate links.
I published my tutorial on writing webapps with Go without a framework,
There isn't much income because I want the book to be free, I'm writing another tutorial migrating the same app taught in the book to use VueJS library.
Fast-forward a few years and I finally built out https://kernl.us as a learning project (Mongo, Node.js, Angular). It's mostly passive income now, pulling in ~$450 per month.
My only new product this year was a 6 weeks video course  in productivity, it makes around $5000 every time I fill a class.
1. http://timeblock.com TimeBlock course
Later, company rules changed and I stopped actively promoting it, but second level referrals still are generating 5-10k year with doing absolutely nothing of work.
Once the website was setup, maintenance workload was pretty minimal (the occasional BugSnag report), so I guess that counts as passive.
I agreed to automated billing with him and he pays per user. I also build API's so he can hire other developers to do stuff with the data and add features.
I myself haven't touched the code for years, but the growth of the database means an extra monthly $1250-ish comes in. Which is nice.
Note: I'm also looking for a partner in this if anyone has any experience let me know.
The web-based version is like a demo, it's free to use but saving and importing is disabled. I'm selling a downloadable desktop app version which has the restrictions removed.
I'm thinking of making it completely free and maybe selling ad-space on there instead.
It's a domain name idea generator. You feed it a keyword and it translates it into 30+ languages and shows you .com's that are not being used. Trying now to get more eyeballs across it. Fun though!
In 2016 i've relaunched https://www.interssl.com/en/ but when i'm being honest there are just too many support incidents. So i just can't call it passive income anymore - even if that was the initial idea.
The margin of sales without support basically just covers the cost for the orders that require heavy support. Remaining income is basically blown for advertising and maintaining the site.
a) think twice about potential time killers - even if the core business model per se is passive, it might turn out to be time intensive ...
b) i'd rather not go into reselling something anymore but rather sell my own product, gives me more financial headroom.
my 2 cents.
$10... For the whole year. App sales aren't the golden goose everyone things they are.
Built with Qt. 14-day trial on Gumroad. Also available on Mac App Store.
MAS version has made me 40$/month. Gumroad version is better (lets you try it and lets you use same license key on all 3 platforms). However, I have sold only one license on Gumroad! I guess the MAS has better discoverability.
 https://gumroad.com/l/ADWm/tasktopus https://itunes.apple.com/in/app/tasktopus/id1039688985
Only have made like $20 off Adsense, but I've got a lot more work to try and get this tool into passive mode:
* working on selecting a date range
* style up the site a bit more
* maybe have users so you can save searches etc
I get very valuable data that the travel industry would probably consider great leads, but I'm just figuring out what to do with it all.
Edit - and fill out these graphs: http://www.averageweather.io/monthly/boston/ma/12/
In the past 8-10 months, it made about $5k+ through sales as well as partnerships with a couple online bootcamps. Not too shabby as I spent almost no time marketing it. Plus it was fun to write since I'm passionate about the topic and I've received some awesome feedback (of the "you actually changed my life"-sort). That was more than worth the hundreds of hours I spent writing it, the small bit of money aside.
To date, I've made $6.31 from that blog post alone. Someday, I'll get over $100, so adsense will pay out.
I've also got an online multiplayer boggle game that has made me low 3 digits per month since about 2008, http://serpentinegame.com, mostly ad revenue but also paid memberships.
I sold a domain I had intended to develop this year to a FB founder for $12,000 and another for $7,500. After researching I found there are few places to buy really good startup domains so I made brandfountain to passively fund my startup(s)!
 http://amzn.to/2hcfuB7 - Work Less to Live Your Dreams
None of them have made a lot of money, but one is still generating a small amount. Guess which. Hint: Income is not proportional with the shinyness of the technology stack
However, this involves 20 or 30 year contracts to buy power from you after you have made the initial investment to purchase /rent land and install the panels.
Wish there were a way to securitize those deals & allow us to trade them like bonds.
That being said, it's mostly 2 designs out of ~35 that sells anything at all.
I'm sure there's some potential in there, but it's kind of hit and miss.
I reach the adsense threshold about once every year, so it's ~70 euro/year. Sad, but I don't spend a lot of time maintaining it.
$20k from a website I built a couple years ago (searchable product catalog with Amazon affiliate links).
Income is step one. Investment of that income is step two.
A "salary" is income that is bound to time worked.
"Passive income" is income that is not bound to time worked.
The key difference between passive income vs investing, is what is being invested. With passive income like salary _time_ is the investment, not money. That's why it's income.
All the comments discussing saving and investment strategies are rather missing the point of the question.
Too many are rentier activity, costing everyone more in the long run. Appropriating wealth rather than creating it.
Hacker news seems to embrace this culture. Surely the antithesis of the early days of computing and the origin of hacker culture.
I think it really just comes down to where your potential customers may be hanging out / searching. For my side project, I've had decent success responding to posts/questions on sites like Quora, where someone is looking for exactly what you offer. It's free too (besides for your time!).
The book Traction (https://www.amazon.com/Traction-Startup-Achieve-Explosive-Cu...) gives a pretty solid overview of different marketing methods/strategies.
Dell Computer Ultrasharp U2415 24.0-Inch Screen LED Monitor
I purchased them from Amazon.com:
This is a 24 inch screen in the 16:10 ratio, at a resolution of 1900x1200. It has four inputs (2x HDMI, 1x Mini Display Port, 1x Display Port). I am very happy with these monitors. I like the 16:10 ratio as it gives some extra height compared to 16:9 screens.
Samsung 40inch 4k - it was going for $300 on Black Friday but it's a bit pricier now. Purportedly you can get (3840x2160@60Hz 4:4:4)
I have a Samsung 40inch 4k UN40JU6500 that I bought six months ago. Essentially you get the real estate of 4 monitors on a single screen. I usually have a browser, my IDE, and 4 terminals open all at the same time while doing development. It only supports HDMI2 input so I had to buy a Displayport to HDMI adapter to get it to work with my MacBook Pro.
This means I want to get something that can also do games and photos, but on the companys dime. I want it to be IPS and it should be 1440+ (27"+ or a WS 34") and it would be nice if it could do e.g. 75hz. I don't need 4k.
The important issue though is I don't want it to look to my boss as though I'm buying really expensive monitor just for my gaming - Ideally I'd like to buy a product that works for gaming but isn't called "republic of gamers predator yada yada" if you see what I mean. So which are the "sleeper" gamer IPS monitors out there? Perhaps something with freesync, or a WS 34 that can overclock or something.
This model would be a good place to start.
It's about $150 more than your budget allows but I made a liberal interpretation of your "$300-ish".
I also have a Magic Trackpad 2 and Magic Keyboard (both by Apple). I feel I'm immensely productive with this suite. With the gestures you feel like you're in Minority Report without the augmented reality.
I thought. Out getting one cheap 4K TV as a monitor but this works better for me as a developer on a MacBook Pro. I can easily run apps in full screen on multiple essentially positionally locked displays and within them snap-to-edges.
For web app development in the left monitor I'll have a browser with the app running full screen and in the right I'll have my IDE in the left 2/3 of the screen snapped and terminal in the right 1/3.
Since they have become fairly niche over the last few years only pro level users buy them, so almost any monitor you buy in this space is bound to be excellent and score far above average for things like colour accuracy.
Also a WQHD resolution at 27" is the perfect size to have two text editors at 16pt next to each other. Or An editor and two terminals, or anything really. It's silly how small HD really is and how cumbersome 6:9 is for "getting shit done".
Why not 4K? Because right now it's still a gimmick and the chances of you hitting a sold-to-chache-in-on-fad monitor is jus too darn high.
It's IPS and sleek.
The stand is crappy and don't expect much from the speakers, but otherwise I love them.
Very thin bezel, high enough resolution, lots of positions. Buy two, keep one in portrait!
"Ironically, only the first commit is signed."
A few of my friends use this (which I wrote): http://lettergram.github.io/AnyCrypt/
You may ask, "when do you really deal with sensitive data?" My answer, is a lot more often than you think... The cool part about encryption, is I can use it over an insecure line to communicate. For example, I can post encrypted text here and only people I wrote it for can read it.
I also stash some dotfiles in my private folder, and it's extremely handy for sharing signal desktop client safety numbers with other crypto minded friends. I use it for my ssh public keys as well.
I've also used it for snippets with coworkers (secrets or no, it's really nice to be able to sent python /keybase/private/foo,bar/test.py in a chat window, and it can be directly pasted without needing to share the script, or relocate the paths in the command.
I feel like I've naturally developed tons of ways of using it at this point. I'll probably come to depend on it, soon enough.
This isn't regular use as I don't regularly have secrets, but I've used it to exchange passwords, 2FA QR codes, and other sensitive data like this, with people with whom I'm remotely communicating with.
Never really thought about using it to share credentials but I might give that a try.
Feature Request: I'd love an easier way to find the keybase accounts for my friends on twitter.
At the time, Keybase didn't have the appropriate APIs to allow third-party integration like that. I haven't checked if anything happened on that front since.
In those situations, I just give them my Keybase public encryption page, and have them enter the credentials and then send me the cypher text. Works fantastic, and much better than just sending via plain text over email or Slack.
 Otherwise, I haven't really found a use for it since setting it up. Would probably be really useful if a tonne of people used PGP, but they don't.
Of course - this assumes Keybase has not been compromised, but that isn't an attack vector I worry about.
I look to hire people who just need a job. People who are qualified, but not overly qualified. People I know will depend on the job for a long time, but not looking to make it their lives. Hard workers - getting there on time, but also leaving at the stroke of 5. Ivy league schools are a red flag. Huge resumes are a red flag. These people will constantly question whether every decision is optimal, prod incessantly at company strategy, continuously try to impress, and are always hungry for praise, recognition, and "interesting work." When they get bored after 6 months, they quit and go somewhere else (remember they can easily do so because of their pedigrees), often to a competitor, bringing company secrets with them.
I need someone loyal, who knows how to take orders without question, and is prepared to do the work that needs to be done day in and day out because they want the paycheck. Reading the above, you might think I'm a terribly demanding boss, but using this hiring strategy has produced a 100% employee retention rate and by all accounts we are all quite happy.
ability to assess tech/architecture risks in apps
experience in devops automation ("secdevops" if you will)
proven skill in communication regardless of depth
The ideal candidate would have all three, but I could settle with any two of these and still be happy.
I am not currently hiring, but I'll gladly keep any CVs I receive and prioritize follow-ups with anyone who reaches out to me directly. Austin/DC for curious souls.
p.s. the web appsec space is in ludicrous demand. If you've got a breaker mindset, you'll probably come out ahead if you read up on it. If you're a developer right now and want to dip into it, I'd suggest: https://www.amazon.com/Web-Application-Hackers-Handbook-Expl...
Trust me, us security folk will thank you. Heck I'd suggest it to non-hackery devs too. It's a good way to find out how us security types see the world.
If you can sit back and pick and choose like this, then how does that square with the mythical "shortage of engineers" everyone complains about?
Aside from the obvious interest in building container orchestration systems, I look for a passion to solve real user problems, not only building a piece of tech.
Bonus points for knowing about Docker or containers or clouds or Golang or security.
More points for meeting users where they are. And the most bonus points for leadership and initiative.
We're particularly looking for someone to lead and/or manage our software eng team building security features into Kubernetes and GKE.
2. Core CSS. You should be able to review Bootstrap source and explain how it works. You should be able to create static HTML/CSS to match UI mockups.
3. Higher level SPA library/framework (e.g. React, Angular, etc). You should be able to demonstrate an understanding of the core concepts of your chosen framework.
I find that these 3 skills are sufficient for productivity in SPA web development.
It's not so much specific tech skills as attitude. We're strong on pragmatism with a touch of pride in doing it right. Pragmatism without that pride in quality leads to hacks that are unmaintainable - obsession over perfect without pragmatism leads to never delivering.
Here is the description for our Backend Engineering role, a really cool new role that we're hiring the first of onto our Platform Team to compliment our Full-stack engineering team:https://jobs.lever.co/lever/7ab138b0-b5c8-425d-93ae-2fc2b051...
Also backend and data engineering roles (C++/Java/Go/Kafka/etc) are in high demand here.
SoundHound is hiring in SF/Santa Clara/Toronto.
Bonus points for recognizing the bullshit parade that is the current startup world. e.g.: NodeJS has value, but it's mostly the same wheel we've had for 20+ years. Or that MongoDB's changelog has consisted of standard SQL features for the past five years and that pgsql would have been just fine (had people read some boyce-codd anyhow).
This shows up in a resume in lots of different ways. For some people it is a rich Github profile. For others it is that they paid their way through college by building websites or apps.
We primarily hire Ruby on Rails developers who work remotely. Seeing in someone's Github profile that they like to contribute to open source and know how to collaborate with other developers are really important.
For 2017, I want to hire more engineers with Kubernetes, CoreOS, and Go experience. My team has deep Linux systems administration experience but we've automated ourselves out of most of the day-to-day admin work of yesteryear. Our future hires will be heavily focused on automation. We've already automated builds, testing, deployment, monitoring, and metrics in a Kube/Docker pipeline. I expect to automate load balancing and hardware deployment in 2017. I also expect that we will adapt many of our non-Kubernetes data services for running containerized in Kube.
Our stack is node.js/React/Postgres so knowing any/all of those is a bonus, but we don't specifically target those skills we instead look for a diverse, intelligent set of engineers who have a strong technical background or a newer technical background but heavy experience in a non-programming field (mathematics, economics, architecture, teaching, customer support, etc; they all have their benefits). Interest in being "full stack", participating heavily in the product management process (strong opinions loosely held!), and a belief in the critical importance of design & UX (unfortunately still heavily undervalued in the Enterprise space...) are important.
Hiring in San Francisco & Washington, DC by the way.
Advice for senior engineers: brush up your practical programming. If you've been in an architect/leadership role, you may be rusty. Make sure you're comfortable on both whiteboard and keyboard.
If you spent the last 5 years writing iPhone apps, we expect you to know iPhone development pretty well. Memory management is the obvious area here.
Be ready to explain the most recent projects on your resume. Think outside the box - if you wrote code to process messages from a black box, how do you think the black box worked? If you consumed JSON messages, how much can you explain of JSON and JSON parsers? Many projects are so narrow in scope that we can't have a meaningful conversation about them, so be prepared to broaden into adjacent areas.
Advice for new grads and early-career engineers: have some solid, non-trivial code on github (or equivalent) and make sure we know about it. Be prepared to discuss it and explain design decisions. Few do this.
This post is my take on the question - what follows is especially subjective and not representative of shopkick:
Don't put stuff on your resume that you don't know. Or, brush up the skills featured on your resume.
Learn a scripting language, especially if you're a server engineer. People who only know Java/C++ are at a big disadvantage if they have to write code in an interview. How big? Turning a 5 minute question into 35 minutes is typical - and it gets worse. One very smart, very experienced man took 45 minutes on such a question. Of course, don't just port Java idioms to Python; learn Python idioms. Good languages are Python/Ruby/Perl. I think a HN reader probably doesn't need to be told this, but just in case. Properly used, scripting languages teach techniques which carry over to compiled languages.
Server engineers should be comfortable with either vi or emacs. And with basic Linux. Personally I find it astounding that a server candidate would be unfamiliar with ls and cat, but it happens.
I hope this is helpful and doesn't sound arrogant.
+ for new web platform things like Service Workers, advanced SVG.
Could care less about whatever franework is hot this week.
We may also need a strong lead for a new business unit, a role akin to 'founder lite' you run a business unit with two others, you have your own burn rate, your own P&L, etc. The strongest skills someone can have for it are former founder experience (aka: broad experience doing lots of things, moving quickly, MVP, etc).
Palo Alto, San Francisco, Seattle.
Interviews have practicals where you work on problems you'll see regularly with skills we expect you to have (like writing code, debugging, and task breakdown). Good communication, pairing skills, quick learning, and taking responsibility for your circumstances stand out.
- scalable architecture with legacy systems
- tech strategies to enable engineers & product to create success
- broad knowledge of useful serverside languages & technologies
- bringing a multi-platform SAAS to multiple regions
- processes and tech to ensure quality of output
- AWS dev ops
But for the sake of the OP, skills would likely be a nebula of PHP, Go, SQL, node, react, Webdriver, kubernetes and tech related to application infrastructure (Kong, Message queues etc). There are other nascent products which may demand other technologies - a years a long time :)
If any of this catches your eye hit me up for a chat firstname.lastname@example.org
We hope to expand our team in early 2016 and have a mainly java micro-services with some PHP and native apps on the front. Will likely add to the java team in addition to an IOS dev.
Nice atmosphere, nice people. We try to select for people who don't like to be micromanaged (but are still friendly) and assign responsibility not tasks wherever able. Varying degrees of success but overall happy with the approach.
Looking for at least one highly skilled person with java experience and ideally a fin-tech background. Not sure the salary would be competitive with SF but cost of living is small and its a great lifestyle (for those who like daily excitement/challenges and learning new cultures). On site. Other roles would likely be unsuitable (read: cheap!) for the HN audience.
We are looking for c# devs with some front-end experience and ops people (linux / Windows / networking). Azure / AWS experience is you have it. You can do SQL and have a nice grasp of distributed architectures. Experience with CI is appreciated.
Most of all though, you need to have a passion for the job. Really like what you are doing and be proud of the stuff you create with the team.
As a company we value your efforts and actively encourage you to have a normal family life but we also expect you to handle a shitstorm (with your team) if need be.
That also holds true in my personal life as what I look for from others and expect of myself.
If you have that, breadth in projects and technology and you are genuinely excited by the opportunity I have on offer then I have found that a good mix.
Experience with the above would be nice. What I actually require though is not specific to a particular technology:
* Not a dick
* Ability to reason
* Ability to iterate
* Ability to communicate at multiple levels of abstraction
You can apply here; http://grnh.se/p4tu8l1
- Developers: We use mostly java, swift, and JS (Angular 2) but we always look for polyglot developers, full stack developers, or whatever you want to call someone that see the language as a mean to achieve a goal and not the goal itself.
- DevOps: Deep ec2 knowledge and experience. AWS certification is a plus
Since it's a jr role I'm looking more for evidence that they want to learn than examples of accomplishments.
* development services and applications on Kafka and Spark
Oil and Gas
Since we also do private consulting and project-based work in addition to our workshops, we have recently got to talking with our clients about helping them get full-time employment. So I think this post is pretty timely and very relevant to us. Here are a few reasons why we think React is important for the job market.
Coding bootcamps are embracing React as well. Since most of these institutions survive year-to-year based on how well their placement numbers are for graduates, they are paying close attention to the trends in development. One could argue that since they are probably more technical than the average recruiter, they may even have a better grip of the pulse. FullStack Academy, of New York and Chicago, recently wrote a blog on why they're moving their curriculum from Angular to React (https://www.fullstackacademy.com/blog/angular-to-react-fulls...). App Academy (SF & NYC) has had React in its curriculum for a number of months (https://www.appacademy.io/immersive/curriculum). And I've personally spoken with alumni of Hack Reactor in SF who said that most students built their capstone project in React (or attempted to).
Is React the best solution? That's arguable, as all things are. It also depends on what you want to accomplish. But for the relevancy of this post -- asking what tech skills people will be hiring for in 2017 -- I would argue that React is going to be one of the top skills. And with that includes...
As far as backend, the top three technologies that we've seen with our clients are:
Anyways, if you are skilled in React and other related technologies and you are looking for work, you can always email me: ben at realworldreact dot com with some info about yourself and/or your resume.
If your doctor refused to renew your prescription tomorrow, what would you use to deal with your pain in its place?
If you lost your job/insurance and thus were unable to afford anything other than over the counter medications, how would you cope with not having this pain medication available to you?
Does fentanyl have a procedure for when you want to stop taking the medication? (like how you should lower your dose over time before stopping with SSRIs and the like)
i appreciate you giving a first hand account from someone who uses this medication!
I think issue with Fentanyl is not the accurately labeled stuff you're getting from the pharmacist. The issue is that since fentanyl is a lot stronger than other opioids, and is easier/cheaper to manufacture, people in the black market have figured out that they can sell counterfeit pills/heroin/etc. that is actually (cut/diluted) fentanyl, and get the benefits of 1) higher profit margin, 2) easier supply chain (no pill mills or poppies needed), and 3) easier to smuggle and store raw product, due to the higher potency. The problem comes when the counterfeit product is too strong -- a user takes what they believe is their normal dose, but it's a lot stronger and they die (e.g. Prince: http://www.bbc.com/news/world-us-canada-37151146).
I've heard it theorized that the high number of recent fentanyl-related overdoses could be because some gang(s) might be trying to figure out the optimal ratio of fentanyl to filler to use in their counterfeit products by watching the overdose rates in low-income markets before moving the counterfeit products into high-income markets (i.e. they don't want to have a rash of stock brokers overdosing).
Applying Hanlon's razor, another explanation might be that these counterfeiters are just mistakenly putting to much fentanyl in the mix.
I assume that fentanyl is no more dangerous than any other opioid when the dosage is correct (I really have no idea, someone correct me if I'm wrong here!).
(EDIT) The counterfeiting issue is a one of the reasons that some people (myself included) argue for legalization of all drugs or at least better harm reduction strategies for addicts: purity, dosage, and quality control would all be better if these drugs were obtainable from more reputable sources.
Unrelated to fentanyl in particular, but a word of advice: if you need to take these meds for an extended period of time, be very wary of any issues with your gut! A very close friend of mine has been on prescription opioids for around 8 years due to some chronic pain issues she has resulting from giving birth; the constipation side-effect eventually caused a bowel obstruction which she ignored for too long, and it has escalated into a very painful and dangerous situation for her, involving several procedures which sounded very unpleasant.
Writers realize that there are other people who can write an extremely well-structured, gripping novel in a matter of months. Artists see their colleagues do live drawing and suddenly understand that something that is painful and difficult for them comes easy for these other people. (I don't have musical talent, but I expect something similar happens there.)
Are they geniuses? Probably some are, but mostly they have just worked very hard and built a set of habits that lets them approach creative problems with that seeming ease.
Making software is really primarily a creative pursuit like these others -- it just has a bit more math and a bunch more high-tolerance engineering thrown in.
Personally I think of programming as a cross between architecture and writing: I'm making something that has a visual presence and which end users can "live in" or "visit" (very much like a building), but it's also a story because the interactive medium necessarily imposes a narrative. This way of thinking helps me figure out the elements that go into software products... But probably everybody must find their own metaphors to make sense of what they want to do in this field.
1. Quantity leads to Quality.This has been written about by a number of people and for good reason. As with any craft, quality is born from doing something in repetition and learning from your mistakes. There is a brilliant anecdote on this from a ceramics class of all things ( https://blog.codinghorror.com/quantity-always-trumps-quality... ). So try lots of things, even if they seem silly. You'd be amazed what a throwaway project in a language you will never again use can teach you professionally.
2. Be passionate about both Coding and Learning.I start to look for a new job when 2 conditions are met. First is that i have been around long enough to see the consequences of my stack/coding/architectural decisions. Second is that i am no longer having "eureka" learning moments with regularity. For me, this inflection point tends to be around 3 years with a company. It will vary for others depending on role and willingness to branch out in your codebase.
tl;dr: Force yourself to learn regularly. Move on when you start to stagnate. Find excuses to code things, even if they are junk. Above all: have fun.
So if you're comparing hobby projects, things that you started working on within a day or two of having the idea...well, maybe that's part of it, too.
If you're looking for something inspiring / actionable to read, checkout this collection by him http://v25media.s3.amazonaws.com/edw519_mod.html
One of my favorite answers -
71. How do you get good at programming?
I believe that there are two ways to get good at anything, "push" and "pull".
Push: You learn from books, classes, mentors, and studying examples, then apply what you have learned.
Pull: You have a problem that you must solve, then you learn what you need, any way you can, to build the solution.
I suppose there are pros and cons of each method, and I imagine that many people here have used some of both.
For the record, I am 100% Pull. I have absolutely no formal training. It took me 2 years to find my first job and then I was thrown into the deep end. It was simultaneously frustrating and exhilarating. There were so many times I didn't know what to do or didn't have enough "tools" in my box. So I had to figure it out and find sources of learning. But I always did. Any when I got that first thing working and then saw my customer's eyes light up, I was hooked.
Your CS degree may make you think that you're a "push" learner, but may I suggest that you adopt a "pull" approach. Forget what you think you know and find a job or a project or someone who has a real need. Then build what you need. You a several advantages over me: (a) It shouldn't take you long to find that job/demand/customer. Just keep looking. (b) You already have tools in your tool box, maybe not the right ones for the job, but you have "something". And (c) It's easier than ever to adopt a "pull" approach. Help is everywhere.
You may feel frustrated, but I don't think you have a problem at all. You're in a great (and very normal) situation. Just adjust you attitude, find something to build, and do it.
The biggest thing that accelerated my growth was working with people who were much much better than I was. You'll learn so much faster, and become so much better than you can ever by just plugging away by yourself.
Just remain humble and open to learning and you'll wake up one day and realize you're actually not bad at this programming thing ;)
"Better than a thousand days of diligent study is one day with a great teacher"
All of them are super-wrong.
All of them are long, hard projects. All of them requiere specific skills, that maybe are hard to know because you don't find much info about how do them (for example, I haven't find good enough, simple material in how build a relational engine).
But do it are easy. Because the "science" behind them is more SETTLED. Is just niche.
> YapDatabase, Audiobus, or AudioKit
I don't know them, but it look the same as the things I'm talking about. I LOVED to have the time or funding to devote to this kind of projects and living from them (ie: I want to build a relational language.)
The most "simple" apps, are HARD TO DO.
Them are easy projects, but DO THEM is harder. The specs are unclear, you can't rely in a cool algo that solve most of it, you can't relly in a big, large, solid foundation, you NEED TO BUILD AND PULL from several sources in how do them.
Rocket Science is "solved", but you can waste months trying to finally know what the hell is necessary to build that e-commerce website.
Just look at the madness with JS. Is now easier doing assembler than that.
So, I mean that the human factors are the uncertain nature of most software projects are a higher burden that the actual "hard" projects.
The way to build big things is to build small things right. Small functions/classes that work correctly, no matter the input. Next up, you wield them to build up a layer and so on. Long story short, you may be missing the concept of abstraction. I say that because you mentioned code interactions; that tells me you are looking at things so closely, the bigger picture seems much larger than it is.
Also, understand that people have different perspectives; that they came up because of some random events. It is a mistake to think people who do a lot of work, think a lot. They don't - They usually have a simpler/more powerful perspective than you have ie, they refactored the thinking required to do a job into smaller number of steps. This is what chess players or the mathematicians do.
Also, you may be aiming too high without background knowledge. An object cache layer for SQL? - Who said this was easy?
Automatic code gen via YAML? - Did you write a toy interpreter before?
MIDI over Wi-Fi? Audio destuttering? - I don't even know what those mean, and Im working as a programmer for more than 10 years, and now in a "big" company.
Do you read a lot? Many of the successful people (coding or other fields) do
May be you can start by reading SICP. It certainly cleared a lot of cobwebs for me.
It sounds too simple, but it's true. My best, most thoughtful, and beautiful work, has been done when I've been intrinsically motivated by the sheer interest and desire to do that work.
In some ways, I was a better, faster, smarter programmer, with 3 months of experience than I am now.
That's not objectively true, but the point remains valid. If you're struggling, you may need to re-ignite that fire. Try and remind yourself why you got into this in the first place. Stop worrying about how you compare to other people, and start building something that excites you. Flow.
I've been re-writing basic algos from scratch, and eventually more complex ones (Dijkstras, Graphs, and etc.), and understanding CS fundamentals helped me get past this hurdle.
... from: https://wrdrd.com/docs/consulting/software-development#compu... )
> How do I get good enough to consistently do work worth writing books about?
- These are great reads: "The Architecture of Open Source Applications" http://aosabook.org/en/
It's scary, to think there's a whole new generation of programmers who probably can learn faster and more fully internalize algorithms and data structures and design patterns... but we can all keep learning. There's no limit to how much you can learn in this field, so to supercharge your work the answer is simple: work 80-100 hour weeks like Elon, but make sure you're actually producing at least 80% of those hours.. meaning, writing and creating code not just reading or consuming knowledge. I don't know how many people I've met that assume poking around reddit, HN or s/o means "working." Those people will never outshine you if you continuously push your limits and are always feeling in awe. That means you're on to something.
Keep it up, you're doing exactly what you should be doing - reflecting.
I would suggest that you stop comparing yourself to them and their achievements. Rather, use their example as a starting point in your pursuit of improvement.
Many others offer good advice here, but one of the cornerstones is to look at what others are doing--often and deeply. Many have asked, "How do I become a great writer?" The answer invariably is, you must be a great reader. You need to read A LOT.
The same goes for math. You must solve problems. That's the other half of the coin. You need to do. So pick a problem that hasn't been addressed. Maybe there's something you haven't found a library or framework for. Take the opportunity to build it, package it, and open source it. You'll see that the set of concerns is different from that of an app developer.
State has to be managed rigidly. If you cannot deduce what semantic state your app is in while you debug, then chances are things will go wrong.
I have found two approaches that work for me: Reactive programming, and good old state machines. The former is needed when there is so much state that the latter would be too complex (too many possible permutations > too many states to grasp).
Every property that your screen has (element A is hidden, element B has this text, animation C is in flight...) should be derived from the current screen's state machine or stream of values. Meaning, state 1 will set A to hidden, B has no text, and C is stopped; state 2 will set A to not-hidden, B has text "xyz" and C is still stopped, etc. It's kind of like React, but on a lower level - properties are overridden or methods are called when transitioning between states. One could call this state machine "ViewModel" :)Swift brought us Enums with attached values, so they are perfect for modeling a state machine. IMO Optionals also prevent some state sloppiness we had with Obj-C's nil behavior.
I'm not saying state machines or Reactive programming are a panacea, but they have solved the problem for me. I'm confident in my code now, and have the feeling that I do solid work (which is good as I'm huge on feeling like an imposter). As long as I use Swift and RAC or state machines, the very most bugs I cause are of semantic nature - e.g. a button text is wrong in such and such state. But crashes or unreproducible behavior are really rare now.
Keep in mind also there's a difference between a full stack app and a focused framework. With the end-to-end app, you have to solve many different kinds of problems spanning many domains. Therefore your learning curve to start is going to be a bit higher due simply to there being more ground to cover.
To get better, you need to write more code and to study architecture of other systems. The collection Architecture of Open Source Applications is a good place to start reading.
With all this said, don't beat yourself up too badly. Facebook has been making changes to mercurial version control to make it scale to work for their whole organization. They chose the less popular vcs because the code of git isn't organised very well and it was too difficult for them to extend/modify it.
Writing robust asynchronous code is very, very hard. My biggest mistake as as a beginner was that in the early days I just made up all my multithreading stuff on the spot. I made a synchronous prototype, and thought, perfect, now I just need to make it asynchronous.
Now I understand that "making it asynchronous" is more work than coming up with the initial implementation, and spend a lot more time on that.
I spend a lot more time on planning in general. I sometimes think about features for weeks or months before I start programming. I'll read all the relevant API docs, search Google to see if other people have implemented similar things before, etc.
Only then, when I'm well-prepared, I actually start coding. And the actual writing is usually pretty quick, but it needed a lot of (invisible) preparation time to get there...
Wow. That alone puts you in the Top 1 to 5% of your peers. Even many experienced programmers have trouble shipping code. They (we) wait for it to be "Perfect". The code ends up languishing in some repo and never sees the light of the day.
1-man frameworks are the wrong things to look at. Don't compare yourself with them. Of course you'll feel bad and inadequate.
Maybe you need to shore up your self-esteem. I say this because your feelings about your own abilities will show through in job interviews, and when having discussions with your peers, and you will get short changed (salary, promotions etc).
So I would say, just keep at it, and try to improve everyday. And don't compete with others, compete with yourself.
Don't get set in your ways (or the ways of those better than you), be willing to try new things and see if it fits your style.
Go slow before you go fast. It took you a month to add copy/paste -- so what? Next time, put in extra effort to try new ways of working, playing with the code, writing invisible support code no one else will see, writing tests perhaps, writing English before code, getting feedback, etc., instead of what I assume your normal approach is of "need to get this out quickly!", and it'll probably take two months, but so what? Eventually you'll get faster as enough experiences have taught you what goes well and what doesn't, but you need to slow down to get those experiences first.
Of course, some people are just super-geniuses. Measuring yourself against them is just a recipe for depression. To quote 'Eliezer:
"...if you have difficulty with any programming concept, you must not be a supergenius. You're just an ordinary genius at best. The sad truth is that there are some people for whom programming comes as naturally as thinking, with code formed as easily as thoughts; and if it takes an effort to understand any aspect of programming, you have just learned that you are not one of those people. Alas."
Personally I believe that everyone has some natural strengths in one domain or another, that gives them an edge to do things a lot faster and can learn and understand things lot faster. For example I can understand technical stuff lot better and can learn new programming stuff lot faster, than I could ever learn playing a guitar or designing :) I believe that the people you mentioned above are excellent programmers/architects and beyond that they have seen and dealt with more situations than any one doing regular programming. They might have built complex stuffs, they have read a lot - books and open source code, cleared the concepts, they have grown their knowledge and they have implemented it where they could. Basically your programming skills improve by doing complex stuff. Applying what you have learn't whenever you get a chance (no matter how simple or complex the product could be). Implementing elegant solutions to problems that can have N possible solutions and no compromises.
I don't say that being a programmer I cannot become a good musician but I think that the music I produce won't match the quality of the code or program that I would write, and even if I could do it - it requires a great deal of effort time and dedication which I wouldn't have required at that scale for coding. I am a programmer first and then may be a musician second. Someone would realize their own strength and work to polish it further, or may be someone would choose to become someone that interests them but it is not their core strength. It's a personal choice.
My comment might be felt negative but I wrote this because I see a burning desire in you to do something and you have been trying it past 3 years, It might be worth to stop and point you to other perspective instead of giving you any standard advice. However if you are determined to take your level up than no one can stop you - all you would require is to rewire your brain - a great deal of effort and strong dedication. Personally I found books and reading open source code to be a good source of improving your programming knowledge and like any art I think the more you do it the better you become. You may also find some job/freelance in some decent company where there could be challenging work/projects - that can help you grow your knowledge rapidly.
1. If you have skilled coworkers doing code reviews (or contribute to an open source project that does code reviews) you will get a lot more feedback.
2. Writing unit tests will provide some level of feedback, but it's not as good for learning as human feedback.
Why do you feel you're doing anything wrong..? If you've released multiple apps (30K LOC is a lot!) you're way ahead of most people who never release anything. Comparing yourself to the most prolific developers is a recipe to make you feel bad about yourself.
Writing 30K LOC with minimal bugs is a massive undertaking by the way. Maybe look into using languages with stronger type systems along with automated tests to help. Also, you could rely on third party libraries to do more of the heavy lifting or just remove/simplify features you don't really need. Either way it just takes a lot of work and time.
Also when you're working for a client ability to communicate and make sure you're building the right thing will trump building the thing right.
- Writing 30KLOC yourself is a real lot
- Maybe it is too much? Try at times to refactor to make it denser
- Good libraries come from re-use. Either a genius came up with something reusable from scratch or someone got better at solving a problem until a piece emerged that was worth sharing.
- Good libraries come from discussion and exchange of ideas. There is a lead but there are contributors too.
- There is a difference between apps and frameworks. The code and not the app is the product and customers are devs. Has implications e.g. how to do marketing.
- Are you made for this? Some solve problems really fast and good enough, then move on. Some others solve problems really well and stick with problems for a long time. Both types have value. Look at your life outside coding for clues.
Second, many successful products weren't all that complex. (though I'm not sure if these days still exist)
Third, realize that most stuff that gets created disappears into the infinity of time & just gets replaced with other stuff.
Fourth... do you love your grandparents? (or parents, or friends) I hope you still have them. If so, then be sure you call them on their birthdays & on holidays. Maybe even send a card. Spend as much time with them as possible. They are truly the most important things to your life. The rest is just icing.
- They are a tiny fraction of the collective. Pretty much everyone else sucks at programming.
- Coding is like working out. Even if you are not elite, you can improve a lot if you persevere. All the way through your entire career, no matter how long.
- It is not all about coding skills. Maybe for those 40k LOC one-man app guys it is, but that's not even the most common scenario anymore. You can compensate with other skills such as being inspirational, having good insights, ability to QA a product/design and identify its weak spots and potential on the early stages, ability to break down a problem into smaller ones and prioritize your tasks, ability to evaluate, understand and communicate with team mates and clients (social skills with coding skills is always a winning combination)... The list goes on and on. Even though it's not all related to programming, it is stuff you'll eventually have to deal with as a professional programmer, specially in the startup world.
Code is reusable. You don't have to be a genius coder to put together a slick and successful app. Even for the most innovative software, the code of every part is most likely already there, written by experts in a clean, efficient, robust and well-documented module you can use free of charge, even commercially. So go on and use it. (I know it's actually not that easy, but mostly piles of crap until you find something useful and learn to use it properly. You get better at that too).
Diagnosing bugs often comes down an exploration of every possible sequence of events, trying to identify the pattern of sequences that triggers the bug, and figuring out how to fix it. In single-threaded code the debugger can make this task easy, but attaching a debugger (or even building in debug mode) often makes concurrency bugs go away, so you are forced to solve the problem in your head by analyzing the system. This experience is like strength training for programmers. I would suggest putting extra effort in the concurrent parts of your code, really try to make them correct. In the end, the practice will improve the quality of your non-concurrent code too.
Also, maybe some people are better suited to solo work, and others to group work where there is some rigor imposed by the team or by the employer. You may be in the latter camp.
Around 5-7 years ago I didn't consider my code exactly high quality, especially when building things from scratch. So I tried to understand what makes good code good, and actually how to spot it. Mostly through reading blog articles, reading actual code and thinking about code. I also got books but only 5 in these years in total. I read only 2 of them through.
So Google is your friend... Have problems with race conditions? There are solutions to that CSP (Golang), Reactor pattern, using 0mq or even STM.
Also don't forget that one things is skill/experience, the other is choosing proper tools. Are you using a simple editor or a heavy-weight IDE? When trying MIDI over Wifi do you Google and try to reproduce the first blog entry you find about. Or do you rather choose high quality components/libraries? # Github stars are a nice indicator for good libs with concise APIs.
But yeah, on the other hand you also need to ask yourself is it worth it? Do you want to be mega focussed and productive? Or do you want to create various things? Being super productive in some place sometimes feels for me a bit Zen-like but on the other hand also a bit boring.
I've hung around awesome programmers too, much better than I. Some you will even have heard of.
Specialists knowledge didn't just fall out of the sky. It takes research & patience.
Some people will always be better than you.
Your focus should be on being better than you were yesterday.
Programming languages are just a bunch of random symbols and letters; each language has different syntax. But underlying them all is the same foundation of how languages are created. Learn to read your code like an essay rather than simply focusing on the sentence.
I'm particularly interested in this thread, "Ask HN: What habits made you a better programmer?":
[Most likely] it is not that they got it right, right from the start. These 'awesome' programmers would have spent weeks before getting it right. These classify as throw away experiments and they keep at it till it satisfies their own internal target of what the solution should be like till it is right.
The best parameter of that right could be say the simplicity of the overall internal implementation and the exposed external API.
Now I am not saying that there are not geniuses around, but even if they are getting it right, it will still be backed by countless hours of hard work and practice.
Most likely asking these awesome programmers how they are getting it right, will throw some more light.
- Every developer out there at some point in his / her life felt the same way as you do. Likely more than once.
- There aren't many developer who can look at their own code written 5 years ago and be proud of it; may be if you are John Karmack.
- Being able to write beautiful code is definitely valuable, but being able to make a product is even more valuable.
- The programmers you mentioned are kind of by definition exceptional. Otherwise they wouldn't get your attention.
You are not missing anything. You are just like the remaining 99% of us. And it looks like you are already trying to get better - so you WILL get better. Every piece of code you read, every book you read, every time you get a code review - you will improve a little.
Sadly, there is no formula to turn an average person into a prodigy. So don't beat yourself up.
None of this comes overnight. Many of us start out incredibly messy, and there is nothing wrong with that.
In fact it might give you an edge over folks that start out very elegant and by-the-book because you are used to dealing with things like race conditions and they expect none.
Remember this, the best code is never written the best it can be the first time around, and in a lot of cases never.
Code is a moving target, stay light on you feet, avoid religion of certain methodology ( to an extent ) and paddle towards things that you are proud of.
You will be fine and likely do great if you stick with it.
Finally, there will always, always be someone who knows more to you. There is no end to what you don't know. The sooner you make peace with this the better!
and clean coderhttps://www.amazon.com/exec/obidos/ASIN/0137081073/metafilte...
If you follow the (admittedly pretty extreme) advice in these books you will be in the top 10% at least.
But when I read the code I saw the code was really suboptimal (tech debt, and sometimes more convoluted than it strictly needed to be). That changed my perspective on code a bit. That did not change my programming rigor though.
My point is that sometimes excellent products are not necessarily excellent from an engineering perspective.
Now, to assess your engineering skills there's a book called the IEEE SWEBOK (Software engineering body of knowledge), that is an index of the different areas of software engineering. You can go through each one and assess your strength and work on some of the imbalances this assessment would reveal.
But for heavens sake, why? Do you actually care about how audio destuttering works, or do you just want your app to work well? Do you want to spend every waking moment thinking about a problem, or take time out to deconstruct Marvel tropes?
And yes, the programmers your talking about are the 1%. Do you think every good dev has books written about their work?
Additionally, many individuals in our industry have zero life outside of hacking on their software. It's difficult if not impossible to be competitive with someone spending every waking hour practicing their craft without doing the same.
I'll guess that you're self-taught, and learnt one of these low-level languages that makes you spend most of your time dealing with irrelevant concerns? I'd recommend going back to basics, learning ML or a similar functional language, and rediscover how to program from the ground up but doing it right this time.
If these developers are already familar with an area (perhaps even implemented it once or twice before), they can do it very quickly. Or have an office/community of people who have, or seen other solutions, or are good at researching/asking online (eg Larry Page asking for help with his java spider; you now).
Consider: how long would it take you to add cut-and-paste to your next app?
Race conditions are a nightmare for just about everyone. Change your architecture to minimize cross-thread communication, and use queues when you can't avoid it.
APIs also can be a nightmare, difficult to understand, don't do what you need, under-documented and of course have their own bugs and required workarounds.
Finally, if you're still spending too much time debugging, you might need to change your approach in other ways. e.g. code only a bit at a time, testing it immediately, so you know what has introduced the bug; write modules that you understand, so once they are debugged, you don't have to worry about them; unit tests can help but aren't essential. It can be helpful to trace through their source code, so you know what's happening.
If you understand what you're doing, bugs are usually easy to diagnose and fix. It's gaining the understanding that takes the time - and, I would claim, is programming.
Maybe there are programmers who, due to prior experience, concentration powers, talent, memory or raw intelligence, are ten times faster than you (or more!). That shouldn't discourage you from creating something worthwhile. Time spent doesn't alter its worth. Provided it doesn't take too long to complete, does this pride in competitive efficiency really matter?
BTW: Worth, popularity and usefulness are functions of the problem solved - not of the solution. A polished solution to a problem no one cares about has doesn't help anyone nor get much attention.
Whereas an ugly solution to a huge problem will change the world. Even mathematicians and theoretical physicists sometimes start with inelegant solutions, though they get polished over time.
It's very good that you've had the experience of writing bad code, and recognizing that. It will make you expect more from yourself next time. And the process repeats. After many iterations you will be much better. And also more nimble. Writing 1000 lines is a lot for someone who has never done that before, but natural for someone who has a million lines under their belt.
If you're looking at other people's code and finding new insights you can apply to your own work, you're doing it right.
When you look at your old code and wonder:
How did this ever work?What idiot wrote this?WTF was I thinking?!?
You're doing it right. It's a sign of growth and improvement.
And now come the downvotes, because I know I am effectively "not allowed" to express this kind of opinion without penalty -- yet I don't care, let's burn it up.
I just realized, I'm pretty sure I'm just passing my 40th anniversary of programming this month. Jeez I feel old.
How I made it this far I have no idea, but here I am still plugging away.
My eyes are going, I get tired easily, and my productivity is a hundredth of what it once was...
I look around here and don't know what half of the posts are even about most of the time :-) In supposed to keep up with recurrent neural networks, the language of the month, algorithms research, which HTML template framework is or is not in vogue, whatever...
Over the years I've written a couple of books, built some pretty cool shit and had the pleasure to work with some of the best, but you know I'm really pretty damn dumb, and the only thing that has saved me is persistence.
I've felt like you many many times on occasion over the years.
Computer Science is a huge subject, and growing by the day, immeasurably larger than when I started. There is no way to keep up in all avenues... and that is fine.
It's pretty normal and healthy to have a bit of a low self esteem about our work as software engineers because it is literally true that every piece of work can be better. Please try not to take that attitude a bit too far though.
You know, I got into this because when I was a kid I wanted to understand how computers work. They were a magical box of wires to me and still are.
I wrote code for fun, my own personal pleasure, and the hope that along the way maybe some of it is of some use to someone else. Maybe even make them smile. That's what drives me and keeps me going.
I think my advice is just program because you enjoy it. Everything else will come.
Financial reward is a side effect, not a cause.
There is no huge race here. Programming is a very personal creative past time that takes an incredible amount of effort for all of us and a lot of patience.
I know it might seem at times looking around hacker news that everyone is way ahead. I can understand that, it's a pretty elite set out here. But... I think deep down, the dirty little secret is everyone feels a bit crap compared to everyone else on here more often than we all let on. Fake it 'til you make it. ;)
Like others said, you have so much to be proud of. Shipping multiple projects on iOS, wow!
The fact you are even looking into audio algorithms and things like MIDI over WiFi is great! Sounds like a lot of specialist knowledge you are building there. I'm impressed!
Maybe one pointer. Step back and stop, take some time and think about the machine instead of the problem at hand. I say that because you mention race conditions. Understanding why they are occurring will be of enormous help. Then when you figure it out, explain it to someone else.
But meh, stop whinning, It takes me weeks to do what I could once do in an afternoon :)
You are doing great.
Keep it up man, it's a really fun road.
Nice you are here.. let it flow.
A likewise naive path is to copy example code, do something slightly different from it, and then wonder why it's broken. You can't be really great at programming by doing that, because you're abdicating so much control to wishful thinking: "I hope this example author considered my use case!"
What you can do - and you probably have the guts to do it, if you're writing 30 KLOC apps on your own time - is to attack things one technique at a time, and to attack the hardest, most lasting stuff first before you get into more specialized and ephemeral knowledge like API calls. It's the adjustment of what you care about that leads you to direct your coding towards unfamiliar yet profitable roads, where you have to envision very big ideas that aren't in place yet, struggle with them for days or weeks, and ultimately find a great technique that you can reuse in the future.
To take one example, UI code is wonderful stuff for adding end-user value. But if you want extreme leverage in your code it can't be the first priority, because it's also stuff that tends to be thrown out frequently - because other features change, or you're on a new toolkit, or you found a slicker design. You have to instead allow the UI to be too crude at first, and think about application features as a layer apart from the UI. And then only as you come towards the end, confident that the core features are correct and will be robust against a partially-working UI, can you go back and invest in a great presentation.
Likewise, it's tempting to make code that is clever in-the-small, at the moment you first dip into making a new feature; to invent class hierarchies and configuration objects and generics and other nifty things. But what you need most at that moment where it's new is the most boring, plain code possible, because if you don't know the problem space yet, anything clever that might add structure or allude to generalizing the problem along any one axis is likely to do so wrongly, and the most flexible you can be is to assume it's all disposable and should be extended with copy-paste-modify. Fancy language features were made to break through problems with the crude techniques, so if you follow with that grain and only add the features after you feel pain, everything tends to go much more smoothly.
Most of all, it's scary to take on seemingly big problems, but it's scary in a way that should not influence your decision whether or not to attack them. These problems feel big mostly because they aren't well understood to you. In the same way that math students are prompted to take on gradually more ambitious levels of abstraction, you have to do the same with your code. You start with your bad assumptions and knock them out with a dash of computer science knowledge, and a lot more trial and error. There will be bugs and bad decisions along the way, but you can also learn defensive techniques against them. Some attempts to defend your code may just make it harder to write or more brittle; others will succeed dramatically. You won't know these things until you try(or get very good advice from someone who solved a similar problem to yours) because every problem domain in programming has a unique solution profile, where some things matter more than others.
immediately followed by
>I'm proud of my work especially design-wise
* Always be solving problems
* Make mistakes, and learn from them
* Just because something didn't work 5 years ago doesnt mean it wont today
* Don't buy into hype
* Be passionate and excited about things. You're not a robot
* Don't feel guilty about wasting time.
* Don't overabstract every problem
* The quickest solution is generally the best solution -- or at least help you understand the problem better. Don't design a large solution to a problem, solve lots of smaller problems.
* Do things that align with your strengths
* Know what your strengths are
* Build relationships with people. Be their friends. Talk to them about non-work related things
* Keep meetings to 30 minutes. Always have a takeaway from a meeting
* Have a life outside of work
* Set goals for yourself. Set goals higher than you think you can achieve. Make a plan for achieving the goal.
* Hold yourself accountable
* Don't be an ass
They hate you because you have skills and they usually failed in their careers (or have a liberal arts degree, which is even worse).
They will record and make public whatever you told in private.
They will blanket spam your CV to every corner of the world.
They will lie to you to make you sign it.
They will make you feel worthless so you can accept a lower package.
* there's always something to learn. You know that, but you'll lose sight of it.
* look at the bigger picture, always
* don't be afraid to ask questions, as many as you need until you have the information you need.
* worry less about what you want, and more about doing the right thing for the customers you're building for. (In the end, there's a surprising amount of overlap...)
* 12 hour days might feel good, but they don't help in the longer term.
* you can't do it all yourself.
* you'll get paid more than you need to survive - so don't be an idiot with your money.
* talk to people. continue to talk to them after you are no longer required to interact with them regularly. Relationships are work, but they're important to your sanity and career.
* Those things you avoid because they're too hard? They're not really too hard, and that's not really what's stopping you. There's nothing wrong with failing.
* Those ideas you have? Do something with them. But one at a time, and make an active choice as to whether it's worth finishing.
* There will always be things that you want to do better. Don't let that stop you from shipping.
* Don't read comments. And for the love of FSM, don't reply to them.
That knowledge will build up with time, and someday, a younger developer will come to you with questions. Take the time and answer them; it's worth it.
* Switch employers every 2 years. Do not have loyalty unless you have stock options.
* Contribute to open source for the learning experience
* Use what works, dont focus on the hot new trends (redis, mysql, django, ror vs express, mongodb, etc.).
* learn at least one functional language really well
* learn one statically typed language really well
* learn one dynamically typed language really well
* multiply all time estimates by some coefficient C, where C is always larger than 1.
* become familiar design patterns described in Gang of Four
* learn the UNIX commands and piping really well, they will save you a lot of time.
* have side projects and dont be scared to show them off!
2. Always test your code, and if you're writing in language you're new with get someone else to code review it. Especially if you're bugs are likely to break your company's main customer.
3. Technology is worthless if it doesn't help you achieve your goals. Software is worthless if it doesn't help you achieve your goals. Figure out your goals first.
4. Put another way, ask "why", don't just code.
(These are all based on actual mistakes I've made. You can get the full story of these and other mistakes I've made at https://softwareclown.com).
And by that I mean be involved in projects from start to finish.
If you find yourself at a company for more than 2 years, and you've only worked on 1 boring project, it's time to look for new opportunities. Now, there could be multiple small projects as part of one big one, that's different, as long as it provides you value and helps you progress in your career.
The only way to progress as a software engineer and get a solid understanding of the SDLC is to keep cranking out projects from start to finish.
There are far too many people that get stuck maintaining a project right out of college, and never experience the full SDLC.
The more projects you deliver from scratch, the better you'll be at estimating tasks, understanding risk, business priorities, etc...
- behind any given reason, there is a complex network of real reasons. You don't need to second-guess any decision/order/suggestion, but it helps understanding.
- most user stories / user requests are raw diamonds waiting to be polished. ("What do they really want me to solve")
Essential reading list:
- Clean Coder and Clean Code https://www.amazon.com/Clean-Code-Handbook-Software-Craftsma...https://www.amazon.com/Clean-Coder-Conduct-Professional-Prog...
- Test Driven Development by Kent Beck https://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/...
* Admit when you don't know something and then rectify it (if it's interesting to you).
* A stable solution is better than the bleeding-edge solution.
* Smaller (simpler) is better. (KISS)
* Learn how to gauge technical ability in a conversation with someone and compensate for that on the fly. Non-techies will love you.
* 80hr weeks will not make the company love you. They will only make everyone else in your life dislike you. And eventually, the people at the company.
* Shop around. You don't have to take the job offers but keep interviewing. You learn as much about yourself as they learn about you.
* Find a problem-space you love and develop it. Tech is tech but business is business. Finding an area that you like to solve tech problems in will make you happy.
* Don't make technical arguments personal. Make your point, with facts, let them make theirs. Agree if you're wrong.
The goal should be continual improvement which includes successes and mistakes. Preferably, these are done at a pace that lets you enjoy your youth, family, friends, and life.
* always be learning, but focus on architecture and design, not implementation specifics
* work hard, but make sure you don't forget to live
* always do a good job, never burn any bridges, and in 10 years things will be great
Also, be open to tasks that are not just hands-on coding. Tasks related to testing, documentation, mentoring, product management, project management, etc. add value to the business and make you a more valuable and versatile player.
- don't spend to much time on exploring tools, but whenever you notice you're repeating yourself often, make sure to do a quick search to see if there's a quicker way. There usually is, because others will repeat themselves in similar ways.
- make sure to find real projects (where you get paid or at least dinged for not delivering) that offer a degree of challenge/unfamiliarity. I've gone months with very little progress in my abilities, only to take on a project with an unfamiliar toolset or environment and learn a shit-ton of stuff that helped my long-term.
- find a mentor!
- look into this 'functional programming' thing, but don't become a convert. It's not the solution to everything.
- if the coding you do for work doesn't excite you, make sure to find some exciting side-project. Programming, at least for me, is so much fun. I've let work take the fun out more than once, to the point where I'm seriously considering finding some other line of work to make a living so I can code just for fun. 'Unfortunately' my front-end work is so lucrative that it's the best way to have as much free time as possible.
And the two biggest ones:
- "Bad programmers worry about the code. Good programmers worry about data structures and their relationships." and "Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious." I can't properly express how much this has improved my coding. I don't think it's a coincidence that React/Redux (often) put such an emphasis on one big state object to work with. If I start my work with thinking about the data structures and their relationship, the code becomes so much easier to write!
- Watch 'Simple Made Easy'.
* Remember that people with non-software skills are probably just as smart and hardworking as you are
* No matter how much more qualified you are than your coworkers, don't fight every battle even if they are always wrong
* Actually read (don't skim) documentation and source code
* After you have some money saved up, quit your job and look for your dream job full-time
* You'll be perfectly happy having never worked in Silicon Valley, or for any prestigious companies
* Read error messages and understand instead of just googling
* Switch mentors often
* Forget about getting rich
* Think in the problem space / avoid thinking in implementation details. Structure your solution along lines that make sense in the problem space, name variables for that, etc.
* Do the simplest thing that solves the problem at hand, but no simpler. Small, simple implementations are easier to change when (not if, when) unanticipated changes come up. If you anticipate additional functionality, leave the door open to those changes rather than writing code for them now.
I took some risks and enjoyed my 20s and early 30s immensely, but also played it pretty safe. I would advise my younger self to take more risks, specifically around creating products.
* Don't waste time & energy learning trendy tech. Hold your excitement and ask yourself: "what can I do with it that I can't do with my existing arsenal and is it worth the ROI?"
* Learn to identify companies that are nothing more than feature factories
* Ownership is better than a paycheque. It means control over your decisions and work quality.
* When working at corp/consulting, focus on the things you can control and the people you can influence. The rest is out of your hands and not worth the emotional investment.
* Learn to let go. Tech gets out of date. Software you spent years working on gets replaced. Stuff stops working because of dependencies down the line. Nothing lasts forever.
* Focus on getting better and investing in yourself.
* take risks, work for a company that wants to change the world
* contribute to open source
* code is read more than it is written, learn to write code that is easy to grok
Know programming patterns. Be able to categorize a problem as an instance of a pattern (or not).
Know what you don't know.
Being better at debugging is more valuable than coding faster.
Train those junior to you as if you want them to replace you.
Use the Socratic method. Ask a lot of questions. Over-communicate.
Be able to adapt yourself to the person you're talking to.
Be able to manage "up." People should trust you not only because you can get things done, but also because they are well informed that things are getting done the way they want.
The main advice I give to junior developers is that state is the core of incidental complexity. Focusing on minimizing state to the degree practical is the simplest trick I know for producing well designed systems. The only place it doesn't necessarily work is high performance code.
- Always judge the business value of any change request
- Be weary of any technology that promises to revolutionise the world of programming
- Get to know the whole stack, even if only in abstract terms, don't focus on silos
- Care about the business side, how the technology meets the needs of the actual users and way of doing business
- Never ever sacrifice private life for the employer. They won't think a second about your sacrifices when showing the door to teams
- Stop underestimating problems, assume they are hard until you can prove they are easy.
- The squeaky wheel gets the oil. Doing great work that no one knows about doesn't get you recognized, and doesn't help anyone.
- Trust your own intuition and insight more. They are often correct about other people and your own life direction, but get ignored too often.
* Don't fall for the line, "We'll fix it later." It will never be "later," and the problems will never be fixed. Do it now, while it's cheaper.
I would gladly have traded off some of my career success for more family time...had I known then what I know now.
* People are more important than code
* Don't fall in love with specific technology
* Do not rush, force yourself to slow down
On the other hand, if you have a good situation (realistic management, decent pay, good co-workers), think very carefully before moving. Such situations are not all that common.
"do you want to work long hours sitting at a computer everyday until you're dead?"
Also, what you are describing is like opening a mechanical engineering shop and saying "we can invent anything that moves". Consider how well that would go. Specialization is the key, at least in the early stages.
If you are good at some domain and believe you can help someone in that domain, you can create and demonstrate your analyses with specific examples. In addition, building a decent blog with personal touch and experience can create "collateral" and it helps keep you make continuous progress in small steps without necessarily focusing on any specific topic.
Follow up periodically so that the company stays in your deal flow pipeline and maybe it leads to work at some future date. Maybe it doesn't.
Doesn't matter what magic the consultancy sells, that's how it works: build a big enough pipeline of potential sources of work and statistically there is always likely to be enough work to keep the lights on. Statistically, if the pipeline is not big enough, there won't be.
The size of the pipeline is based on the rate at which the consultancy burns through money; the aggregated probabilities of each potential client to produce paying work each month; the rates at which clients cancel projects, fail to pay, or choose an alternate means of accomplishing their goal; and the amount of time it takes to complete a project (e.g. $10k over two years versus $10k over two weeks).
The larger the consultancy, the bigger the pipeline needs to be. My advice is to start putting numbers into Excel.
For most consulting jobs, the client has a clearer idea of what they are going to get. You might promise them a working SAP system, advice on a document they might sign, a tax return they can file and so on.
With data science, you might just be promising them: hey, we will take a look around in the data and see if we can find something interesting.
This is a harder sell. I think you need a clear example of what you might find and why that is valuable to the client.
Strategy consulting firms often deal with similar issues. I do think that it is not easy to land pure strategy assignments unless you are already at McKinsey, BCG or Bain.
When I go back down this path, I'm hoping to bootstrap with a Blog instead. Not necessarily because I think this is the best idea, but because I think it will be more fun.
There are tons of free data sets out there, find something in a vertical that you think has a large market share and blog about it. Run and crunch those numbers on your own dime, make your visualizations beautiful.
Hiring a content marketing consultant would be in your best interest and might be cheep.
Talk a look at your local/nearest industries.Pick a medium sized one.Get to know them and take a look at the machines they use for QA.
You'll be very surprised to see that, in some industries, quality test could take dozens of hours (you cannot speed up chemical reactions).
If you can infer the quality of a product based on easy-to-accquire inputs, then you have a customer.
Given the technical complexity of Storm and Spark, this might be a situation where paying a consultant for assistance makes sense.
I've just been building stuff out in Node/JS-land for a while and just want to give something back to the community. So I'm thinking about starting an e-book or a series of blog posts to educate people in things that I've learned. Learning people's use cases gives me a better understanding of how I can write things that genuinely solve pain points.
I would really appreciate it if people could PM me some type of contact info so I can keep in touch with anyone who is interested. My email is tilomitra[at]gmail[dot]com.
I did build a complete web app (basically a Reddit clone) in NodeJs from scratch recently (though Angular2 instead of React), most of the things that you described in your book's contents were in the official documentation or tutorials (and Stack overflow).
Still, I don't know things like server-side rendering, and although I was able to configure SystemJs I have no idea how to configure it (or its de/merits over bable/webpack), 3rd party authentication (Google/FB login) was a pain, and now I realize I should have used the Flux architecture and also used TDD.But then all this is just a google search away anyway.
However, I would have paid for the book you describe if a) I wasn't broke, b) was just beginning with web dev, c) the book built a complete nontrivial app (something like the Meteor/Telescope).
PS: Which nodeJs framework would you suggest/use?
Yes, after an introdutory free and useful by itself chapter/course.
Constantly looking for this kind of learning resource right now. I had a very good experience with this one: http://trysparkschool.com
In my personal case, as I'm learning to code from scratch, it is essential that the course do not assume too much about my previous knowledge. Check the Twitter course. It teaches me how to install everything from the most basic tools, like Terminal. It actually taught me what Terminal is.
I hope you do it, I very much need it. Get my email at the profile and please let me know if you do it. Good luck!
A book is by definition 90+ pages long (probably a lot more). I will only want that much information if I'm completely new to the area.
I have never used Node.js nor React, but I did a fair amount of web design. A book will feel slow and repetitive.
Case in point: the last book I read was about Opencl. About a whole Chapter was dedicated to configuration parameters and C data types. I know that stuff has to be there in case the book is your only reference, but otherwise I can just check the Internet for that.
I know lots of people like technical books for pretty much the same reasons I don't, so keep that in mind too.
Most importantly, if there was a way for you to host the ebook online and provide a way for someone to type code into your website and mess around with the source code. Think like Codecademy, with code on one side and the result on the other.
One obvious search mechanism is, of course, Stack Overflow. HN's Algolia search is another. Personally I run Searx locally and permanently have it open when coding.
Judge yourself against genuine accurately measured metrics. Hold yourself to some minimum/acceptable/excellent standards.
Problem: You are at increased risk of turning into a hermit.
Expectation: I must attend no less than 6 meet ups per year (roughly 1 every 2 months). I should strive for 12 per year.
(Some of you might say that's too low, you can adjust for yourself, don't get too excited by setting yourself stressful goals.)
Have some excel spreadsheet or something and measure it.
The gist of my suggestion is one word, quantify.
This can be easier said than done and it's certainly not the only option. However it's a good option because metrics don't lie and in the absence of other methods to keep yourself in line you have to rely on an honest source of truth.
The second best practice might be remaining aware of all those risks.
The third best practice? Perhaps realizing that all of those things are sort of normal among ordinary humans and just to accept that fact.
Anyway some things I've found useful:
Freelance: Do work in a company first because it (hopefully) gives some exposure regarding QA/CR and generally putting code out there. The whole process. For deadlines, if you have a deadline you're about to miss you better work harder and require a longer deadline for the next project. Each new project I take on I require longer and longer deadlines, if it is impossible just say no.
Solo: Use the app/service yourself constantly for the bugs, create beta tests for the rest. I've found that you only need 1-2 people as beta testers if they are genuinely interested in the product. I've had essay written to me about features.
If you were your only employee, would you be happy with the output?
Pair up with another solo shop for pairing/code reviews.
I am by no means an expert in this but the following things helped. At present my time is limited and if I don't take efforts to monitor my activities, I easily fall prey to distraction and procastination.
* Maintaining a list of things to do. If the first thing you do when you sit down to work is wonder what is it that you have to tackle next, thats a recipe for loss of productivity. If you have a list of tasks ( as granular as possible), ordered by priority if possible, you can hit the ground running.
* Try to have more realistic expectations of what you can accomplish. Try to estimate how long each task will take for you to do and then double that estimate. Knowing how long each task is gonna take will cut down on anxiety.
* If you are a solo founder starting out, product validation is much more important than QA. Once you have customers though, it is important to avoid any disruption in services.
* Release often even if only you will see. Make incremental updates. Always start with something very small but working and keep adding features. Immediate visual feedback of seeing your changes at work will do wonders for your morale.
* If you are doing multiple projects, some preliminary documentation should be in place so you can context switch easily from one project to another
* Though all these help me a lot, I have just started following most of them and it needs lots of discipline. I need to be mindful of what I am doing. Whenever I slip, I just try to get back up and start again.
* I also need to find a way to handle situations where I run something and it needs a minute or two to finish. I end up wandering to HN or News or Youtube and lose track of time. Maybe another list of micro tasks :)
Another idea is to use spacemacs. I have been a vim user for a long time. The idea of using emacs for browsing , task tracking and coding sounds appealing as probably there is lesser chance of distraction. Can someone comment on whether it is a good idea or another wild goose chase?
All that said, if I am exploring a new feature or tech, it often lacks structure due to it's lack of clarity and the time estimate for it is widely off the mark. Yet to find a way on how to tackle this. For now, the only option is to set some hard deadline. If there is no light by the deadline, that line of exploration has to be dropped. Maybe the unpredictability just has to be embraced and accepted.
Also, there was a website with stackoverflow kind of setup for solo founders and freelancers to interact and 'feel like an office' setup. Unfortunately I have not used it in some while and forgot theurl.
Yes, I know of one well-known company which gave one of its core team members an unlimited leave of absence (with a believable promise that they'd be welcome to come back any time in the next 2 years). The key aspect here is that this was a small-ish, (then) family-run company -- and in many ways, the team was like family, too. Also, this was well before the current hyper-accelerated "My startup's growth plan ber alles" ethos that we have today -- so even aside from the family-run aspect, people at least did generally have some perspective on the human side of things (unlike today).
I feel as if the best thing for the business is to let go of him, but it's a shitty thing to do.
Absolutely. Definitely don't just fire the guy. (Aside from being a shitty thing to do -- I'm assuming it's abundantly clear already that there's a significant chance that could backfire in ways that could hurt the company far beyond the current loss of productivity).
But (absent an actual, forced leave of absence) it may be a good idea to ply him with a significant amount of paid leave (4+ months), with a suggestion that he put aside any idea of working full-time for quite a bit longer than that -- plus a statement that he's not only welcome, but very strongly encouraged to re-apply at any time after 6 (given that it's basically too complicated legally to outright promise someone a position will be available for them in the future, given the way business conditions usually go -- which I'm sure he can understand, in his current condition).
Things happen in life, and sometimes you just have to do the right thing.
This seems like a bigger issue to me than the one in your subject.
His disappearance should not affect the validity of your vision and the validity of the opportunity.
If his disappearance is demotivating this is a sign that your motivation needs work.
If you fire him something else will replace him as the conditional hook that will trigger the demotivation.
You can fire him or keep him. But your reason should not be that his presence is demotivating.
Or rather if this is your reason you will find yourself demotivated anyway, regardless of what you do.
I would start getting palpitations followed by dangerously high blood pressure. Touch wood, nothing major happened to me and I'm back to normal life.
If you guys can cooperate with him and give him the time, I'm sure he will come back to leading a normal productive life.
Like someone suggested, give him an indefinite leave of absence and have him work with therapists and recover fully.
From a business standpoint, it's an unlucky break. From a personal standpoint it's a profound tragedy for your cofounder. If the business is viable this won't be the last encounter with bad luck. How this one is handled will set the company culture.
My random advice from the internet:
1. Google up "grieving process". You won't discover how to fix it because there ain't no fixing it. It might help you understand what your cofounder is going through and suggest constructive ways to help.
2. The tragedy effects all three of you. That's why there's demotivation and frustration. Group counseling might be a way to work through the current situation. Relationships are one the things that counseling strengthens.
3. Reframing your coworker's condition as grieving rather than depressed puts it in the right light. It acknowledges the proximate cause and places the sadness within a timeline. More importantly it recognizes that the condition is not pathological or a mental disorder. It's simply a healthy part of the human condition.
4. Suppose you and the other founder kick out the grieving cofounder. Afterwards, there's still just the two of you. It is nice to imagine that the business would be in the same shape that it's in now. But it won't be. It will have gone through the distraction and disruption of removing a founder. On top of the disruption and distraction that the death has already caused.
5. Ultimately the business decision is whether to lawyer up or to team up. I hate sports analogies, but here one would be managing a squad where someone has blown out an ACL. The person can usually return to full fitness but it takes time.
At the very least, you should minimize information related to the time-frame and size of your team.
I don't have any recommendations for which action to take next. But do try to speak to him honestly and open up to each other as deeply as you can not only to find out what action you should take next, but to come to a decision together.
Lately I bought some Pantone notepads, they come in several sizes, sturdy and have dotted guides.
But 99% of the time I just use cheap 99 notebooks.
I am now waiting for remarkable (https://getremarkable.com)
I'm not a hiring manager, but as the CTO I do review a lot of resumes incoming for technical positions we are hiring for.
The vast majority of applicants do not appear to be taking any time at all aside from selecting their resume to upload and clicking submit. It doesn't seem like they even read the job requirements, since 90% of them do not meet the minimal requirements we post. Some of them are not even developers, but they apply for a developer position.
If someone does appear to be relevant and did also include a cover letter relevant to the position, I will respond, regardless if they're a fit or not.
For me the biggest pain is the sheer amount of irrelevant submissions, which makes you numb after a while. This is why I don't believe in job postings anymore and mostly do headhunting.
Hope this helps!
Dear [First Name],
Thank you for your time and interest in a career at Snap Inc. At this time, our team has decided to evaluate other candidates for the [role]. However, we encourage you to apply in the future for positions matching your goals because our needs change frequently. Thanks again!
Best wishes,Snap Inc.
They must receive an enormous amount of applicants from all over so even though I didn't make it anywhere in the interview process, I'm appreciative of receiving a response and getting closure.
When I was employed, our HR department used Monster's ATS. They found it difficult to use and didn't bother to inform candidates of their application status.
I have been in the situation before where replying to everyone with anything meaningful is simply not feasible. Maybe for a recruiter whose full-time job is that but not for a hiring manager who also has to balance their regular duties as well.
I have spent much more time on the applicant side of things than the hirer side so I understand the goal. It can be frustrating to not get anything. If it is a job you really want you may be inclined to hold everything else off until you hear something just on the hope that maybe they haven't gotten to your resume yet. So a little closure would be nice.
So maybe a better question for you is what are you trying to accomplish by getting hiring managers to reply to all candidates? Give them closure or provide feedback? If the former than maybe a simple "no thanks" will do.
By the way, I am speaking clearly to the scenario where a candidate sends in a resume and doesn't hear anything back. In my opinion, even if the hiring manager or recruiter does a phone call the candidate deserves a clear "no" email at a minimum.
We will respond to everyone that gets past this first round. And if you get a phone / in person interview we will definitely call you back to say 'no sorry'.
By filling out the application form on our website, you load all the information into the form for me, and are guaranteed that a recruiter will follow up on your entry. If you want to send an email to the hiring manager as well to explain why you are so awesome, that's fine, but it's probably not going to help your chances of getting a job any more than just applying.
They sent out a mass email about 3-4 days later saying they had 550 applicants they were trying to sort through- so hold tight basically.
Now I pretty much know I'll get a mass email "no" if they don't decide to interview me. Which is nice.
When there's no effort put into applying for our position, I don't see the need to put effort into a reply ... And eventually a flag in our system will send them a generic rejection (approved by legal I'm sure).
On the flip side, we're currently looking for a Google-style SET to work on testing Enterprise Java software and have received almost no resumes that fit the position as we envision it ... That's a pretty clear indication that the job description we posted needs work.
EDIT: This position is still open ... My email is in my profile if you're interested.
I generally give an immediate answer to 1 et 3.2 are applicants that may do the job, but I am not really convinced, don't seem as great for the job as 1, and want to see them only if nobody in 1 gets the job. Also, 2 is definitely all the applicants that never received any answer from me, because I don't feel like telling them a straight no (in cas I'd need to interview them), and the job process usually takes a very long time. In the end, I either forget/procrastinate/feel like it's been to long to decently answer, so no answer.
As I said, I'm not proud of that, I know this is bad and not respectful to applicants, just being honest at how bad I am at the recruitment job.
If you want somebody to critique your cover letter and resume writing skills, interviewing ability, etc. I'm sure you can find somebody to do that. But they will charge you for the service.
It seems a bit silly to expect some random company's hiring guy to provide you that service free of charge.
(That's at resume review stage. If a candidate has actually talked to you, including any kind of interview, then they deserve a response, and I do follow up with everyone who gets to that stage.)
Target a small handful of companies strongly relevant to your experience and interests, and start informally chatting with people who work there. Ask about the culture. Get coffee. Ask how they like working there. Talk about what you've been working on that's related. Ask some questions about interesting problems they're trying to solve. Be interested and interesting. Points for going straight to an Eng VP or CTO -- even if they don't have the time to talk to you, they'll pass it to one of their underlings who does, and when your VP/CTO tells you to follow up with someone, you do.
The resume should be mostly a formality AFTER they've expressed some interest in your skills and have invited you to formally interview.
And if it doesn't pan out, you've already made personal connections with people there. Get coffee again for feedback.
Replying to every applicant, the majority of which are borderline spam, is just extra work with zero added benefit to the business. Even if you make it easy, it is extra work. Not to be heartless, but people might then actually reply to you, and you spend more time dealing with someone you didn't even want to interview in the first place.
I get that as an applicant, this sucks. But as a hiring manager? Full communication with every applicant is MORE painful. And that is why they do not do it.
Goes to 403 Forbidden. Atleast put something in there???
Message: Access Denied
All other pages, including Pricing page, work tho ;) https://www.hireloop.io/#pricing
Phoenix: Good one if you need lots of concurrency especially for an uptime bot, or a chat service or similar style app. This one's on my to do list.
Laravel (is a very profitable one php is everywhere and has good integration w/ Vue). This is my bread and butter, and I really enjoy using laravel and would recommend it to anyone.
Beginner or Advanced: Python - Django, Flask
HTML&CSS (Not languages)
Python(numpy/scipy) & R are perfect for starting (and open source!).
LastPass is great but there was a breach last year, in which they claim nothing was compromised and they offer a free plan.
It's never let me down.
- in a domain that they understand
- if given suitable tools
I've seen musicians do things I couldn't begin to draft an implementation of, thanks to domain-specific environments like Max/MSP. Their understanding of audio mixing, musical timing, and signal processing mapped to the development environment _and_ workflow intuitively.
It's humbling when you struggle through basic DSP, then a guitarist shows you a complex algorithm and shrugs it of with "its just like lil effects boxes, dude."
Watching him debug was eye opening too. As if tracing a buzz on his guitar's signal path, he patched in after each node to confirm the output at each step, like I'd do with a debugger on each line of my code.
His context was so beyond my understanding though, picking up on issues further down the signal chain by noticing frequencies that would feedback, clip or cause phase issues. It really showed me that an understanding of the domain and context of what you're trying to achieve trumps nearly everything else.
If you have paid any attention to the society you can see the different classes of personalities. Some of them, naturally, are polar opposites.
For lack of a better word the "artsy" types are generally not "cut out to program".
The people that are cut out to program are generally in a small subset of the "thinking" types.
I know I'm generalising but that's the point, you can almost never state something about a large population and have it hold true or false in all cases so exceptions exist but they are negligible.
Try explaining binary to that kid in your school that loved ballet dancing and theater. You can see a part of them die in their eyes in the first 15 seconds.
Try it with that other nerdy kid that keeps to himself and you see his eyes shine as he has the ah-ha moment. Chances are he doesn't see "the point" of dancing, too.
These differences exist and they are everywhere all around us from a young age to adulthood. Denying it doesn't help anybody.
The answer to your question and the music one is YES. Not everyone is going to be A Mozart or a Torvalds, and thats OK because it takes all stripes to get things done.
All it takes is motivation, dedication and practice to master programing (or an instrument).
Programming requires a certain amount of abstract thought that not everybody is capable of. As far as I can tell, there's a direct trade-off between spatial reasoning and abstract reasoning.
Programming requires very abstract, logical thinking - not everyone's brain works like that. Learning programming also requires a ton of patience and determination (chasing all those bugs) as well as the ability to learn large amounts of arcane syntax by heart.
Not everybody has these skills, or the grit necessary to put in the required hours of training. And why should they? I don't see this as any kind of huge societal problem... After all, we don't go around demanding that everybody should be able to work as a carpenter, or a lawyer, or a surgeon. You do what you do best, and that's all there is to it.
Those of us who learned in high school and college have the passion for programming that drives us to succeed. Not everyone has that passion.
To be honest a lot of people have problems learning how to program. I worked in a college computer lab back in the DOS and Novell Netware days. I've seen people struggle with trying to program or debug. The process is very stressful unless people know how to handle stress.
HN claims fake it till you make it. In a way this is true as you learn and practice programming. It keeps your confidence up and the more you do it the better you get.
I'm sorry if I've missed something, but isn't the status quo a reasonable option?
Other than that, see what other problems your current customers are having that you could help with. Basically you do not want to leap into a completely new arena and start from zero again (some people can pull this off, most don't). Your Delphi to C# thing appears to be a good example of the sort of transitions you can make.
Alternatively, do personal projects on things related to your hobbies or stuff like that. It's a great of motivating yourself and learning new stuff. Often enough, you will find that there is actually a market for what you built.
Also, find dev meetups in your area (assuming you live close to or in a reasonably-sized city) and go there. You tend to get free pizza and there are always people with interesting / intriguing ideas. Sometimes the people themselves are interesting / intriguing.
What kind of work do you really want to do?
What would be an ideal mix of workplace elements relating to your health and working with colleagues and where you would live?
How much do you want to stretch? Python and Django are in a way similar to C# and webforms in terms of the type of work and concepts while F#, Scala, Haskell, Erlang, or Clojure would probably be less familiar?
Do you want to work in a setting with a few other developers? Or a lot of other developers?
Do you want to work with *nix boxes in addition to Windows? Work with Systems on a Chip? Distributed computing?
My random advice from the internet is to spend some time examining the wide range of possibilities. It's not that you're likely to get them all, it's just that you might have a better feel of what you're getting and not getting.
Competitive analysis is, I suspect, one of the more popular reasons, and not much public info on that...for obvious reasons.
That's what I'm doing to learn.
- See how a page is structured (does it use schema.org's stuff?). Its fields, URL pattern, sitemap, resource urls, selectors, etc.
- Fetch a page.- Parse it and extract data.- Save data.- Rinse, repeat.
I'm also learning about D3 and many cool things.
Check out http://atlas.media.mit.edu/en/profile/country/usa/
As to your target audience, I think you'll probably serve the Many-Faced God. In a gold rush, people who sell shovels make a good living. You probably want to make something that helps with decision making or triggers buying according to price (from your description).
Naturally reading this has spun some ideas in my mind - it would be cool to build a system where people are incentivized to respond to issues, and having it on the blockchain removes a lot of the trust issues that comes along with payouts and rewards.
Any thoughts on this?
Preferably, like you, I'd rather this be user-oriented, like a kickstarter for features or issues, rather than just paying developers for implementations, but I will confess I didn't look at BountySource too closely. Perhaps it would fit both our needs.
Or someone else can come in and say "I'll do it for X".
Most successful projects that I know of are those where the developer is actually getting paid for his work. QGIS is a great example.
Some good methods:
The technique called Five Whys developed by Toyota. http://www.aaronsw.com/weblog/geremiah
Socratic questioning used by a lot of scientist: https://en.wikipedia.org/wiki/Socratic_questioning
Essentially, I try to develop domain expertise via empathy.
1. What are you trying to do?
2. Why do you need me?
3. Why do I need you?
It is available everywhere so no need to install or configure it, and the language is so compact you can keep most in your head and not need to .
Even though it is marketed as a language for text processing, it is very flexible. I even finished a lot of Project Euler questions with it.
I think static site gen is probably another area where make could be quite useful.
I constantly see people blindly typing `ps aux', `ps eax', or `ps -Af' andgrepping through the results. This is stupid. ps has so many processselection options, including command name (I regularly use -u, -C, -p, --ppid,and -t).
The other aspect is its output formatting. Again, so many fields can bechosen, fine-tuned for either ease of processing or displaying on the screen,but people tend to stick to `x' or `-f' formats for no good reason at all,relying instead on text processing after ps has done its job.