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.

Uptime isn't the hardest part about running a solo SaaS shop -- you can solve it by a) bringing an appropriate amount of professionalism to engineering choices and b) choosing to found a business which has appropriate uptime constraints relative to your resources. Don't do analytics or infrastructure software where a 15s blip in your availability causes hundreds of pagers to go off. There exist many things businesses use which have markedly lower uptime than every SaaS a HNer will ship -- remember, businesses are built around most of their vendors having five twos. (That's a joke, but it isn't a joke.)

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 built Jollyturns (https://jollyturns.com), a ski and snowboarding oriented business. I currently have a fairly extensive web site, and two mobile apps, on iOS and Android. I started with the iOS mobile app, I wanted something to show me on a ski resort's map where my friends are, and keep track of my skiing statistics.

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.

Being by yourself, you need to be prepared to be a full-stack engineer. I built my own Supermicro servers, and host them in a colocation facility. I found that if you're in it for a long time it's cheaper this way. I run Kubernetes for cluster management, Postgres with PostGIS for database, Redis for caching, nginx for web proxy. Server side is written in a mixture of Python and C++. Web frontend is AngularJS (JavaScript). For iOS I write C, C++ and Objective-C. On Android I use Java.

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!

I haven't done this, but if I was going to, I would target an existing platform that big companies depend on (salesforce, slack, more niche CRM's, etc.) and create a super focused niche plugin that 1) Is not core value prop of the platform, 2) Has little chance of being duplicated by the platform, 3) Has no competition, 4) Solves a real problem companies have.

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.

Running solo doing around $750k/year on a desktop app. The market is so huge and so many niches to filll. Make something you can sell for $50-300 with upgrades once in a while and set up a simple shop. It has never been easier to develop desktop software. If I was going to start this route today I'd 100% make an electron app and try to address and already large market that has stagnated or has shitty entrenched players making a ton of margin.

Totally viable. As a micro ISV you have practically no expenses so the only things you need are a mediocre product and handful of customers and you're already sustainable. Once you get to that point tons of options will present themselves.

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!

Not the same thing exactly, but I'm able to run 2 ecommerce sites with non-trivial sales volumes, by myself.

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.

Yes its definitely viable. I started my micro ISV 6 years ago, its been quite successful about $200k/yr. Its very niche. I do no marketing but get regular sales through mainly word of mouth and internet searches. Now some bigger companies have picked up my software and use it in house and OEM it. Took a lot of work to get started and a lot of learning Its difficult for competitors to make something similar in a reasonable amount of time so its got a nice moat around it at the moment. I have no employees and almost no overheads so all revenue is profit. The most useful thing is when other companies build around your product, they provide valuable test / customer feedback which greatly reduces the work load.

Yes, it is absolutely possible. I have been doing this for years focusing on niche SaaS products that are too small for VC funded or big companies to go after. I am currently bringing in $20k/mo from my SaaS stuff (3 different niche products) and additional revenue on top of that with adsense/affiliate stuff.

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.

Balsamiq Mockups is a good example that microISVs are still viable. At least, Peldi (the founder and sole dev initially) started off solo some years ago, was solo for a while, and became successful while still solo. Then got some employees over time due to more growth.

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.

Edit/update:

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.

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 :)

Yes it's possible. I've been doing it for nearly four years now running networking infrastructure software which has even stricter requirements than a typical SaaS business.

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.

Yes. I am my boss's only employee, and I only work part-time while studying. Before he hired me, it was just him. We develop software for the real estate industry for property management and trust accounting. We have one major client that we work with directly, and we have a specific version of our software that we only supply to them. We also have a partnership with another company overseas who we license our software to, while they handle client relations and support.

It appears to working out quite well for him, as he is currently on holiday overseas.

I recently tried to become my own ISV. I produced the first draft of https://conciergeapp.uk/ within 2 weeks after a chat with someone who is in the Facilities Management (FM) section. Initial interest in the market looked good and I had plans to make a modular platform. After some refinement etc, I totally failed to sell it. I tried so hard but it was exhausting. Then I got a regular job, but still.. this does appeal. Wish you luck! The hard part is not the coding.

sure, i do it. Develop a custom system for a company and then charge a monthly use and/or maint. fee. If the original development was tested well you are essentially getting free money every month.

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 :)

I think it is doable. I write a few desktop apps (text editor) for OS X, Windows, Linux, iPad and I have a few games in the app store with more coming. Some days I pull my hair out from the stress but overall I am happy writing the products.

I had such a project that was making about $15k/mo at its peak -- it was me and my wife, barring a couple of spot contributions from contractors. It depended on data from a sole data source, a Fortune 100 company, which eventually cut us off by sending a C&D threatening to sue under the CFAA, Copyright Act, and various other statutes. They claimed we breached the contract entered automatically by using their site, as their Terms of Service states that "no automated or manual method" (i.e., no method at all) can be used to access their content and their footer states that use of the site constitutes agreement (this is called "browsewrap"). The way we accessed data was much lower-impact than the way our clients accessed the data previously and I'm fully convinced that we saved them tens of thousands in maintenance and bandwidth costs.

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 do. As advised by others comments, I sell a plugin on a platform that takes 20-30%. It's great because they handle the invoicing to big companies, which removes the hassle of being a referenced provider.

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.

First step apply. With that background, you have a high chance of getting a job straight off.

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.

Can you find an industry collaborator to work with on a research project? I'd wager someone in your department is willing to bend your ear about interdisciplinary collaborations. Finding (or proposing) something interesting, then applying data science techniques could yield learning, funding, and publications. Rinse and repeat until you've got the skills you want or the new job you want.

Could collaborate on a project that I am contemplating as well as testing out bits and pieces. One thing though I probably am located very far from you and the project would be more of a research project. If interested a few rounds of emails might become a path to follow.

just do what you want to do the best you can do, and learn as you go. mistakes happen and you learn from them. There are plenty of academics who have moved to industry in your field, may be they can chime in. but you should just apply, and go from there.

I work in manufacturing. We have an acoustic microscope that scans parts with the goal of identifying internal defects (typically particulate trapped in epoxy bonds). It's pretty hard to define what size/shape/position/number of particles is worthy of failing the device. Our final product test can tell us what product is "good" and "bad" based on electrical measurements, but that test can't be applied at the stage of assembly where we care to identify the defect.

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.

The entire product I built over the last year can be reduced to basic statistics (e.g. ratios, probabilities) but because of the hype train we build "models" and "predict" certain outcomes over a data set.

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.

We're a computer vision company, we do a lot of product detection + recognition + search, primarily for retailers, but we've also got revenue in other verticals with large volumes of imagery. My co-founder and I both did our thesis' on computer vision.

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!

Here at Matterport, our research team is using deep learning to understand the 3D spaces scanned by our customers. Deep learning is great for a company like ours, where so much of our data is visual in nature and extracting that information in a high-throughput way would have been impossible before the advent of deep learning.

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.

One of my coworkers used basic reinforcement learning to automate a task someone used to have to do manually. We have two data ingestion pipelines. One that we ingest immediately, and a second for our larger customers which is throttled during the day and ingested at night. For the throttled pipeline, we initially had hard coded rate limits, but as we made changes to our infrastructure, the throttle was processing a different amount than it should have been. Sometimes it would process too much, and we would start to see latency build up in our normal pipeline, and other times it processed too little. For a short period of time, we had the hard coded throttle with a Slack command to override the default. This allowed an enginneer to change the rate limit if they saw we were ingesting to little or too much. While this worked, it was common that an engineer wasn't paying attention, and we would process the wrong amount for a period of time. One of my coworkers used extremely basic reinforcement learning to make the throttle dynamic. It looks at the latency of the normal ingestion pipeline, and based on that, decides how high to set the rate limit on the throttled pipeline. Thanks to him, the throttle will automatically process as much as it can, and no one needs to watch it.

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.

At Persyst we use neural networks for EEG interpretation. Our latest version has human-level performance for epileptogenic spike detection. We are now working on bringing the seizure detection algorithm to human-level performance.

The startup I'm part of uses ML to predict which end users are likely to churn for our customers.

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. :)

We exclusively rely on ML for our core product at Diffbot: automatic data extraction from web pages (articles, products, images, discussion threads, more in the pipeline), cross-site data normalization, etc. It's interesting and challenging work, but a definite point of pride for us to be a profitable AI-powered entity.

We use ML to model complex interactions in electrical grids in order to make decisions that improve grid efficiency, which has been (at least in the short term) more effective than using an optimizer and trying to iterate on problem specification to get better results.

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.

In my last job at a big telco I was working with/on a scorecard driven next-best-offer system steering 80-90% of all outbound callcenter activities. I would not call it AI/ML because the scorecards were built with good old logistic regression and were pretty old (bad) but the process made us 25 M /year (calculated NPV). I don't know how much of it was added by the scoring process. We also had a real-time system for SMS marketing built on the top of the same next-best-offer system making 12+ M /year (real profit).

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 leverage machine learning in the asset replacement modeling space. Basically there is an optimum time to sell your vehicle and purchase a new one based on our model. Our company works with large fleet organizations and provides analytics suite for vehicle replacement, mechanic staffing, benchmarking, telematics and other aspects of fleet management.

We use Convolutional Networks for semantic segmentation [1] to identify objects in the users environment to build better recommendation systems and to identify planes (floor, wall, ceiling) to give us better localization of the camera pose for height estimates. All from RGB images.

Once an analyst has manually reviewed something, a software system updates a row in a database to mark it as done. Our marketing team calls this machine learning, because the system "learns" not to give analysts the same work twice.

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.

I work at Periscope Data - we do our own lead scoring using home-baked ML through SciPy. It was interesting to see it play out in the real-world - interpretation of features/parameters was definitely important to the people driving the marketing/sales orgs.

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.

Machine learning is great for helping you understand a new dataset quickly. I often train a basic logistic regression classifier and introspect the coefficients to learn what features are important, which are unimportant, and how they are correlated.

There are a number of other statistical techniques you can use for this but scikit-learn makes this very very easy to do.

I think a lot of the real benefits from ML "at work" is more in just cleaning of data and running through the gauntlet of simplest regressions (before jumping onto something more magical whose outputs and decision making process you can't exactly explain to someone).

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.

At Graphistry, we help investigate & correlate events, initially for security logs. E.g., Splunk & Sumo centralize data and expose grep + bar charts, then we add visual graph analytics that surfaces entities, events, & how they connect/correlate. "It started here, then went there, ..." . We currently do basic ML for clustering / dimensionality reduction, where the focus is on exposing many search hits more sanely.

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 grammar checker that used both ML models and rules (which in turn used e.g. part-of-speech taggers based on ML).

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.

Providing users the best recommendations so they participate more, get more from the service, and churn less. Detecting fraud and so saving money. Predicting users who are about to leave and allowing us to reach out to them. Dynamic pricing to take optimum advantage of the supply and demand curve. Delayed release of product so it doesn't all get reserved immediately and people don't have to camp the release times.

At ScreenSquid we use statistical analysis to find screen recordings of the most active users on your website. This saves our customers a ton of time avoiding playing with filters trying to find "good" recordings.

I run a company that specializes in design & implementation of kick-ass ML solutions [1]. We've had successful projects in quite a few industries at this point:

LEGAL INDUSTRY

Aka e-discovery [2]: 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).

MEDIA

Built tiered IAB classification [3] 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.

REAL ESTATE

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.

LIBRARY DISCOVERY

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.

TRANSPORTATION

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.

BANKING

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.

Most of these seem to be very on the side of "I'm a company", so as a sole developer what I like to do for clients is implementing sockets into their apps.

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!

My answer here is more relevant to an e-commerce company but the basic idea can be adapted to any company.

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.

Whenever I find myself at my desk not knowing what to fill the next few minutes with, I tend to call a more or less random customer - the ones who USE our products, not the ones who procure them - and ask them what they think suck about our current offerings.

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! :)

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.

When I did freelancing, I charged a bit more than I felt I should... but went above and beyond. My hourly rate may have been high, but I spent many "non-billable hours" making sure everything worked great and any changes (their fault or mine) were accounted for.

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.

I never disagree with a client. Even if I internally feel it won't work in reality, I always start my response with "That's an excellent idea you proposed, let me try if it works and get back to you". I come back after a day or two as to why the proposal won't work (if it was a bad idea to begin with) with sufficient data. Client is happy you that you considered his proposal and you've avoided a potential standoff that could've existed for the same duration !

Here's an internal facing one: We send an automated greeting from the CEO as part of onboarding, but he actually sees and replies to every customer response, in both english and spanish, and forwards the more heartwarming ones on to the entire office.

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.

I do hardware engineering work for hire and one of the things that always works is having some documentation ready at the first formal meeting.

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.

Call them out when they're wasting money on marketing. This has been in my "blog post drafts" folder for a while, but the short version is: One of the first things I do on new projects (I'm a customer acquisition consultant) is review the running campaigns and their results from the past few months. Not clickswhich is what all the dashboards show youbut actual results like signups and new customers.

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.

Consistent updates(mostly daily) on email with screenshots and quick short screencasts. A lot of times a particular feature takes more than a day to complete and be pushed to some server for client to actually see what it looks like. But if I create in progress screenshots and videos from my dev machine it always impresses my clients.

One thing we did a few years ago when we found that a customer didn't use revision control was to bring in a server. A small PC with Linux, Subversion and Trac. We not only could explain the benefits of RCS, but the customer could see changes, att issues, get them resolved etc. When the job was done, the customer kept the machine.

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.

Lower their prices, without prompting. At Flexport we sell logistics services. The price of ocean freight is highly variable (less dynamic than, say, the stock market or airline seats, but still fluctuates a ton). We make money by brokering these services. In some cases, the price of freight drops in the time between customers when contract us (and agree to a price) and the service gets executed (when we contract with the asset owner). We pass those savings on to the customer and let them know. This usually results in big joy, all around.

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.

I'll add one here from my own business, which is customer care outsourcing. The outbound call. Basically it comes with the territory when things go wrong. But when you call the customer before they realize things have gone wrong they are always, always grateful and impressed. Same thing goes for a "just checking in to see you are enjoying the service" call. Since we have agents sitting around all the time anyway this is time that can be used to call up customers and impress them.

Look at how many of the answers in this thread are simply about communicating effectively.

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.

1. Deliver just a little more than they expect. Most times when we write a web app for enterprise customers, we try and give them a little bit of extra functionality than they ask for. One example is the user profile settings for their sign on to our web apps - most customers are only bothered with having a username and password, but we often incorporate things like ability to choose avatar images or upload their own images against their profile.

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! :)

Something we were doing when I had a web design agency was to have awesomely beautiful and detaild proposals where we summed up the context, constraints and goals of the project. We considered them as our first deliverable and spent time creating beautiful indesign templates. It allowed us to stand out from the start.Another thing is while our competitors were usually not showing anything yet at this bidding stage, we were already delivering some high def mockups, sometimes within the weekend.Last thing, we didn't have any sales people. Meetings with leads and customers were directly being handled by tech leads and lead designers, who were not there to sell, but to advise and find solutions with the client, explaining and integrating the client within the process from the start.All in all, we won all the biddings at the time despite being usually 30% more expensive.Something we were doing also is to include free perks that didn't cost us anything and was making a lot of difference for them ( free access to our email marketing platform, server monitoring, etc... ).

My business develops mobile apps for clients. They love when I analyze major announcements from Apple / Google and explain how the new features may apply to their apps. They feel they have a partner, and it typically results in new development for us.

I am a developer and usually writes web scrapers or automation tools most of the time beside typical web development. A couple of things I did and worked for me.

- 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.

I work in a large health organisation right now and the thing that seems to blow most away is just saying yes.

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 don't know if these things "blow them away" but I do think they are differentiators:

- 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."

Build much better UIs than my competition. It's a known issue, we developers rarely take the time to bother with UI and it's a shame because it makes all the difference in the world, especially in web apps. Clients can't tell technical superiority, they can only judge from what they see and if your UI is stellar you'll make selling a lot easier. And you know, judging from the fact that so many of us are afraid of the sales side this could be a lifesaver. Build better UIs to counteract the fact that you suck at sales.

Show them how to do it themselves, and teach them "why" I do things the way I do them. I write resumes for clients and do them in Google Docs, and I invite the client into the doc from the very start. They can actually watch (in real-time, if so inclined) the work being done at all stages in the process.

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).

Using web dev tools / inspector during a screen cast demo, either to modify a style or to show a site/app's responsive behavior. Simple, I know, but it comes off as some form of wizardry to many clients.

I am in a pre-sales position so I am already typically on the clients shit list. Unlike most of my counterparts, I have lived in the world of ops and development and know how fun it is to get a call at 3am when something is down. I use my past experiences to explain to the customer why I would do things a certain way or why I think something might not be a good fit. I listen to what the customer has to say (something many in my field seem to not understand) and try to come up with something that fits well for THEM, not for my bank account.I have had multiple people from various companies I have worked with tell me that they really appreciated my honesty and I typically get great customer satisfaction reviews, even if the project doesn't go that well.

Our clients tend to be blown away by map widgets. If we showcase an application and then bring up the embedded Google Maps view, e.g. with different kinds of overlays, most clients are completely blown away.

I am the web developer/web designer that usually picks up where other web designers left off or "disappeared". They usually leave without a trace or they leave their client with a broken website. I also take them from being charged a fortune down to being charged a much fairer price. I know I could probably continue to charge them a fortune, but I just don't do that to people. I tend to go after people who are on a "shoe string" budget. I mean.. I charge them enough that I'm being paid for my time, but I am willing to work with their budgets.

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.

On our real estate listing / brokerage site, we have a "GET MORE INFO" button on every property. When a user hits that they'll get an automated response with a title report, but then our agents will follow up the same day with a short note about the property and any additional info we can find. The human follow up tends to be a magic moment and if our agents are able to provide some juicy info, the customer usually sticks with us for their purchase.

As a consultant and advisor, I add value in the sense that I move my clients forward very fast, whatever they need at the stage they are. Need strategy? We devise a plan together. Need sales? We make calls together. Need r&d? I have a network to rely upon. Need introductions? We have a look at the sector and agree the approach. Need a deliverable? We have a look at capabilities and try the shortest path to put out something for sale. Need services? We test the market together. Blowing away = moving forward efficiently, safely and as soon as possible. That said, the ultimate problem everywhere is sales, so just help clients sell their sh*t and they will be happy, very happy, very very happy.

I wouldn't say "blows them away", but apparently, customer service is generally bad enough that these things often provoke a pleasantly surprised reaction:

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.

Mobile app development - releasing a binary download (MVP) in a few days which delivers the bulk of the clients required functionality.

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?

What a great question. I find it's always the little things that do the trick!

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.

I get marketing, developers, content-people, biz-dev, product, higher management, middle-management ... in one room ... and after 2 days we produce a prioritized roadmap on how to move the company forward. Plus: No dead bodies, they actually liked beeing there.

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.

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.

Requirements analysis in UML blows a lot of my clients away, it lets them see the world in a different way for the first time. I don't think I'm great at it, shows how rarely this is really done for large institutional customers.

Speaking as an independent IT consultant: Listening and trying to truly understand the problems they have (at least I try to do that as much as possible). Then solving those problems in perhaps unexpected ways. It might sound a bit trite but from my experience business software development often tends to get stuck in a rut and less than optimal or even harmful practices are perpetuated because "it's always been done this way". Cargo cult is an eminent problem in business IT processes that goes unchallenged far too often.

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.

Onsite engineers for UAT and rapid bug fix turnaround. Most bugs reported from customers, during UAT, are fixed by the next morning for another round of testing. This is not always the case, but for most issues, we turn them around in less than 12 hours and the customer is blown away.

Organizing their 4,000 pg VA claims files that are essentially their last 30 years of private and VA health records (usually already organized by facility though), military service, military medical, and the VA claims process

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

Build better products and gracefully handle every scenario. I was always blown away by the attention to details Apple gives to its products compared to others. For eg. Just a video on stress testing water proof behavior of Apple watch

Breville coffee grinders are impossible to get internal parts for. I designed a 3D printed upgrade for the main wear-part in their BCG800XL SmartGrinder.

The storefront is through ShapeWays[1] and I use ifixit[2] 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.

Young hackers who have a surplus of income and have funds to spare that aren't being channeled toward debt / family / donations, heed me: save as much of your salary as you can, and put it in boring investments (index funds / etc), probably through vanguard.com (no affiliation, I just use them and have heard nothing but good things from people I trust). You can pretty easily set up your job's direct-deposit system so that a portion of your salary goes directly into your investments without you ever seeing it, it's a good set-it-and-forget-it system. It adds up over time!

This was pretty accidental, but to motivate myself to complete the arduous application process for my professional engineering license, I creates a WordPress blog documenting the process. Also because I thought I would learn something new (setting up WP blog) and this seemed very "shippable". I completed the application process over the course of a year and haven't written a blog post in over a year.

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 $.

Previously, as a developer evangelist with Twilio, I had to know the tech events and tech leaders in my local community. While I didn't figure out a repeatable approach then, in late 2015, it hit me.

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.

I run a number of side projects and have done since the mid 1990's. I started in business when I was 21 and I'm now 47, so definitely considered 'old' to some of you on here! I've been o reader of HN since it came out, but rarely a contributor. A few comments from me and a link to some of what I've done and how they have done in 2016:

- 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!

Unfortunately not 2016, but two years ago when the Samsung Gear Watch came out a friend of mine got it right away. We went out drinking the same day and when we came back at night we put together a watch face while still being drunk. We uploaded it, set the lowest possible price 1$, and... Nothing happened. Everywhere in the admin panel it showed 0. 0 downloads, not a single dime earned, even after a few days. We were devastated.

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!

i own a decent amount of tesla stock and 2016 was a great year for lending it out.

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.

I co-wrote a book on user acquisition and co-created an accompanying video course to climb out of debt left over from a failed startup.

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 wrote Hello Web App and Hello Web App: Intermediate Concepts (http://hellowebapp.com, they're learn-to-build-a-web-app books using Django) and self-published both in 2015.

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.)

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.

My brother and I have built a couple of test prep sites for UK medical school entrance exams: https://www.bmat.ninja, https://www.ukcat.ninja . BMAT Ninja made about $25k this year (up from $16k last year) and UKCAT about $10k.

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.

My passive income is quite standard. Three apartments in a new block. I bought all of them four years ago when the construction was still unfinished. This got me a good price. I knew that the area would be under continuous development, therefore it won't be hard to find renters. I was right. Best part is that I didn't even have to furnish them. I managed to rent them all unfurnished.

I do have portfolio of small web apps: tools for learning music notes, non-latin alphabets, language flash cards and so forth.

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.

ZoneWatcher - Side project of mine to monitor your/your clients' DNS services and alert when a change to a zone has been made. It serves as a revision history & alerting system which has been helpful when a client fucks with their DNS and expects you to put Humpty Dumpty back together quickly.

I launched it a few months ago and have a few smaller subscribers with a handful of larger subscribers.

My passive income has mostly dried up this year. Years ago I built an automated webshop deployment system for a bloke who makes hundreds of small websites a year, and dozens of webshops a year. The deal was that I'd build it for free, but I'd get a fee per shop he deployed. This worked out pretty well for a couple of years, but now he's swimming in money and is retiring, and my passive income source has dried up.

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.

Here in Brazil we have it easy. The most boring funds (the ones which track the interbank rate - CDI) easily return around 12% per year (depending on the administration fee; the smaller the administration fee, the higher the return). With the inflation around 6% per year, this gives around 6% returns before tax. If you stay with the fund for at least two years (and it's of the correct kind), the tax rate is 15% over the gains, so you have an after-tax return of around 5% per year above inflation. And that's for a fund which basically never gives negative returns.

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.

In early 2016 I purchased commercial real estate, got a 25 year fixed rate mortgage, and leased it. This requires very little of my time every month, and the post-tax yield is above 5%. I couldn't be happier.

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.

I used to do index funds. Then I went looking for an active portfolio manager. After a few years I found one, he was good, but 6mo in he switched jobs and left for another career.

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.

I'm making between $3'000 and $10'000 Dollars with native apps/games and html5 games. I made much much more a few years ago but app store revenue is decreasing each month and all my latest apps made me nearly nothing. (My portfolio: http://intermediaware.com).

Domain sales, over US$ 2M/yr that could have been mid 7 figures easily but still holding onto those other gems. With all the new extensions valuable .com domains is where it is. Brokers managing sales. Also not sure if falls into passive or not, sold a business few years ago and did the financing, still getting paid monthly for few more years.

Helpmanual.io is my first attempt at passive income. Launched 6 weeks ago and traffic is building nicely. There's still a fair bit to do but the delight of sites like this is you can make improvements when you want. Shame that ad income is less than it used to be but we'll see how it gets on.

I work remotely and moved into an RV to travel around North America with my wife. Started blogging about travel and working on the road at http://therecklesschoice.com and using Amazon affiliate links whenever appropriate that pull in about $50/month.

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.

I wrote a guide on how to get around my local ISP's requirement to use their crappy modem/router combo and recommended a verified-working router with an Amazon affiliate link. Since Jan 1. I've pulled in $160. Very nice since I host at nearlyfreespeech.net and the site has cost less than $1 in hosting this year, and $10 for the domain.

Started a hosting company: its very small and only offers shared hosting right now, but it is almost making money. I never wanted to get into hosting, but so many of my clients were using Godaddy etc I just had to get them away from that chaos.

Note: I'm also looking for a partner in this if anyone has any experience let me know.

It seems like the vast majority of employment contracts prohibit side projects like this, or at the very least, require explicit company approval. I'm interested in hearing strategies on how to best pursue side projects without violating one's employment contract.

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.

My conclusions:

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.

Tasktopus, is a lightweight, task manager for the desktop (Mac OS X, Windows and Linux). Tasks are managed on a Kanban-style board with Backlog, Doing, Done and Archived columns.

Built with Qt. 14-day trial on Gumroad[0]. Also available on Mac App Store[1].

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.

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.

I wrote a blog post about three years ago about doing single-sign-on stuff between salesforce and google by writing a google appengine app that acted as a SAML IDp. At the time, salesforce didn't speak OAUTH and google didn't natively speak SAML, so you had to do it on your own. I put it on an old blog I had laying around and turned on google adsense.

To date, I've made $6.31 from that blog post alone. Someday, I'll get over $100, so adsense will pay out.

an android app that pulls in about 500 a month. i coded it years ago and literally have not thought about it this year until now. it used to bring in about 700-800 a month but i finally got some competition after a few years. i've noticed the app game is tightening up

Built an saas document management & review site for a very large company 3 years ago. I have a monthly maintenance contract with them and receive about $3,500 per month. After expenses (insurance & hosting) and my partners split I net $1,300 per month. Over the last 2 years, I have invested an average of about 2 hours a month, most months I do no work at all.

I added an animated GIF exporter to my lossless screen recorder Claquette (macOS, https://www.peakstep.com/claquette).The project got some traction when Apple featured me in the Mac App Store this August. It also entered the Product Hunt front page and finished in the top 3 on launch day.Revenue is nothing spectacular, but it's a nice additional income.

I've written a book on using Cubase with a general grounding in music, recording and music technology [1]. Income has been very patchy, and never what I'd hoped for at any point. Best month has been around 450, but that's only happened a couple of times (I don't know why, either, unfortunately), usually it's more like 40. Made about 2000 in total, so definitely not something to retire on. Unsure as to whether it's the market for the book, the quality of the book (I hope not and don't think so given the positive feedback I have had from those who have bought it), or a total lack of marketing that's at fault. Not entirely passive as I've had to update it for each revision of the software that has come along, which takes around a week's full time work.

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)!

I have a rental property, it's not much, barely breaking even on mortgage payments, but the hope is I will have the principal as an asset when the mortgage is paid off and any payments coming in will be pure bonus.

I make $1,400/mo from Google AdSense. I made a Wordpress website for people who want to find information about other people. I don't do anything on the site anymore besides perform Wordpress updates. It's basically changed my whole life and I am very fortunate/lucky. Throwaway account.

There are tons of different ways to market your side project and what works for someone else may not work for you, of course.

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!).

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.

Steals the question: I have to get a new monitor for dev work. I work from home so the office also houses my personal gaming/photo editing rig, meaning this screen will be both my home and work screen.

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.

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.

Sounds like you have Macbook Pro only. I think you won't enjoy any non-4k or non-5k display. I have a Dell 27" as the main developer screen and sometimes I love to read on my Macbook Pro 13" retina. I will save a bit more and wait for a cheap 5k in next one or two years.

So WQHD monitors are generally above that price range, but I would seriously suggest you consider investing in one.

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.

Actually had this conversation last week with some other devs at my job. This suggestion is coming from a coworker not myself but he likes using curved screens - here is an affordable one in your range (27")

I recently got a Dell UltraSharp UP2516D, it's great, also because I stay quite close to it. At work I have a Dell Ultrasharp U2715H, I stay like 10 cm further away. I don't see much difference even if one is 25" and the other is 27". I can not recommend them enough, my macbook air's display seems tiny now :D

Multiple smaller monitors over 1 big one. I use the main MBP screen plus three E2414H dells that I got for <$300. I have to context-switch so much less. I'd take utility over "ooh these colors look really good". 1080p @ ~22" is "good enough" pixel density too.

I remember asking for a smaller monitor and getting some weird looks. To much screen space and I'm always turning my head left and right, was hurting my neck. I prefer virtual desktops and a tiling window manager.

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 saw keybase.io as a public key directory which makes it easier to find friends, family and colleagues public keys. Thats my intended use of Keybase.io.I havent actually used it yet for anything serious, although Ive found ways to use PGP public/private keys to encrypt and decrypt local files on Mac and Windows, e-mails using mailvelope or keybase.io so that should take care of everything. But if people dont adopt it Ive got no use for it. And people around me didnt take to Keybase as such its just sitting there so that maybe eventually I can use it. Right now its kind of useless.

At my company we use Keybase to help us validate keys for new employees as we bring them into the fold, since the company is 100% remote. We also use KBFS for some tasks as well. You can see more in the article I wrote for our company blog about our using of GPG + Keybase + Git + Hub for commit signing + KBFS at https://eligible.com/blog/commit-signing-with-git-hub-keybas...

I use keybase.pub to host a whole hugo [1] site. It was very easy to put it together. Updating it is just a hugo + rsync to my keybase public folder.

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.

Sharing .env files full of secrets to bootstrap a project. Typically just dev credentials, not production, but still a nice way to hand those semi-sensitive data around easily, and without committing them to git.

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.

A run a small app development studio, and have a couple times a month where a client needs to share login credentials to iTunes Connect, Google Play Dev Console, Facebook, etc.

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.

Allowing people to verify my message came from me without needing to setup PGP themselves. They can just use /verify and throw my message into it.By using the signature consistently it raises red flags when a post of mine isn't signed or doesn't verify.

Of course - this assumes Keybase has not been compromised, but that isn't an attack vector I worry about.

I am 100% owner of an internet company making 7 figure profits annually. I am extremely secretive of my business, almost to the point that some would consider a pathology. However, I will divulge my hiring strategy, because even if everyone uses my method, there will still be many employees for me to choose from.

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.

So given that I may likely be hiring in the web and mobile application security spaces again next year (I've _somehow_ filled all of my open positions this year; appsec is difficult to fill with external hires), I'm focusing specifically on three skills:

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.

Interesting. Lots of picky responses here--people prepared to wait it out and go through tons of candidates looking for perfection: Need this language. And that platform. Must know such and such database. And DevOps. Front end and backend. Full stack. And these four key abilities. And passion. Prepare for the interview. Be ready to explain this and that. Be good at whiteboard coding. Went through 400 candidates.

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?

FastMail in Melbourne is going to be hiring for skills in three languages: middleware (Perl), frontend (Javascript) and support (English) early next year.

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.

I work at SoundHound as a Senior Software Engineer, and take part in interviewing/hiring. Full-stack JavaScript engineers are still in very short supply. Lots of people claim to know JavaScript but many fall short when working across the stack. When I say full-stack, I mean being responsible for building and managing everything the front-end webserver (NodeJS), Database (Postgres/MySQL), and front-end (usually ReactJS/Flux).

Also backend and data engineering roles (C++/Java/Go/Kafka/etc) are in high demand here.

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).

When I am hiring for Aha! (www.aha.io) one of the key things I am looking for are people who have shown an interest in software development beyond just a day job. The best candidates are those for whom writing code is a passion - something which is done for fun rather than just a way to make ends meet.

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.

I run Technical Operations at Revinate. We are based in San Francisco but my team is 100% remote. I'm based in a small town in Kansas.

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.

I'm at shopkick. We're a mobile app. We hire server, Android and iPhone engineers, but many will move across these platforms. We look for smart generalists. So, although we use Python on our servers, we don't expect server candidates to know Python.

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 hire frontend and mixed web devs. What I'm looking for is a mature understanding of the web platform from devs at all levels. + basic architecture and good practices for mid-level devs. + business and deep architecture for seniors.

Things in our full stack (Python, React, Ansible/AWS, APIs), a focus on strong front end engineers that are interested in mentorship-type roles. There's a unique-ish role for someone to come help us solve remote office work (think piloting VR or new techs to enable me to work closely with someone 1,000 miles away but make it feel like they are 2 feet away). Focus on security/devops.

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).

On the frontend side of things I'm looking less for specific framework experience and more for overall programming competency. JavaScript development moves so fast now that it really doesn't make sense to scope your hiring to angular, react, etc.

Ability to read code daily, write code when necessary, SQL, understand APIs, and be good in front of enterprise customers. We went through 400 candidates to find a quality Implementation / post-sales Engineer. We're a B2B SaaS company.

At JDA our hiring will vary, but my division in Store Operations needs people with SaaS experience, especially with GCP. Angular, REST, DDD, and agile thinking are a bonus. But also need C#, ASP.NET, Web API, and ExtJS for other teams. Have a few spots with strong math skills too, doing complicated forecasting and scheduling work alongside PhDs.

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.

Like many here, Perkbox (London) is less looking at skills, and more looking for experience in:

- 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 ashleyc@perkbox.co.uk

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.

I hire people who show some passion for what they do. On technical end I'm looking for python developers, polymer/angular on javascript end, and ideally at least some basic linux skills.I like candidates that undertstand why languages that allow something like "foo" + 5 are not the best idea ever.

I always look for people that are clearly very technical but who I feel I want to work with. There are some amazing developers that have zero people skills and for whom the word pragmatic doesn't exist. If you can explain complex technology in a way my CFO can understand you will also build a product for that level of user as well.

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.

Our company uses mostly legacy C# and .NET frameworks on premises with a mix of SQL Server and Oracle. We're building a new app using WebAPI / MVC with a SQL Server backend that will be hosted in Azure.

- 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.

I am looking to hiring a jr ruby or elixir developer in the next few months that doesn't mind cross training on the job. They will probably be remote since I live in a small surfing town half way up the Australian coast at the moment.

Since it's a jr role I'm looking more for evidence that they want to learn than examples of accomplishments.

Data presentation. There are boatloads of data analysts who can do all kinds of clever analysis of all kinds of data, but we're finding that the real crux is presenting those results to the relevant parties in a way that they can quickly see the data that they actually need in a way that makes it as easy as possible for them to make the decisions they actually need to make.

I work at Real World React. We specialize in training engineers on front-end web development, specifically React, Redux, RxJS, and related technologies. We've trained engineers from Twilio, OpenTable, NerdWallet, Tesla, Esurance, and many more. We are based in SF.

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.

Lots of companies are choosing React for their front-end these days. It allows your front-end devs to embrace the full power of JavaScript for the front-end -- no more messing around with jQuery and tons of plugins. Sure, there's a bit of a learning curve, like all new things. But there is now a large and devoted community to React and it's only growing. A personal friend of mine convinced his boss to greenfield their entire app with 10,000 lines of jQuery, and rewrite it entirely in React. He was a new hire (and also a great communicator/salesman).

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...

ReduxWebpackImmutableRxJS

As far as backend, the top three technologies that we've seen with our clients are:

PythonGoDocker

But of course, all of this is moot without the foundation of strong JavaScript skills. Our students who have strong JS skills pick up React quickly -- those who don't only get confused.

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.

First, I'm very sorry you have to deal with such a difficult issue, and I'm glad that something is available to help with your pain. It is very unfortunate, IMO, that many people are having difficulty getting the pain meds they need due to the drug war.

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.

For what it's worth, you're feeling the same combination of awe and doubt that grips almost any creative practitioner at some point.

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.

To quote Ira Glass here:"Nobody tells this to people who are beginners, I wish someone told me. All of us who do creative work, we get into it because we have good taste. But there is this gap. For the first couple years you make stuff, its just not that good. Its trying to be good, it has potential, but its not. But your taste, the thing that got you into the game, is still killer. And your taste is why your work disappoints you. A lot of people never get past this phase, they quit. Most people I know who do interesting, creative work went through years of this. We know our work doesnt have this special thing that we want it to have. We all go through this. And if you are just starting out or you are still in this phase, you gotta know its normal and the most important thing you can do is do a lot of work. Put yourself on a deadline so that every week you will finish one story. It is only by going through a volume of work that you will close that gap, and your work will be as good as your ambitions. And I took longer to figure out how to do this than anyone Ive ever met. Its gonna take awhile. Its normal to take awhile. Youve just gotta fight your way through."Ira Glass

There are 2 things i feel correlate strongly with the best devs i know:

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.

I am in my late 40's, I have been coding since I began uni in 1987, I have a Computer Science degree. When I got out there 25+ years ago I was all about doing things the best way, code reuse, refactor etc to get things just right. Most younger devs are. It took so much time getting the environments perfect, unit tests, etc. The customer paid for that, my managers must have been tearing their hair out watching us faffing about doing crap that ultimately didn't lead to a better experience for the customer. I am much more experienced now and live off my own skills, I have about a dozen apps on the iOS app store the number of users is 7 figures, they bring in good coin. The code behind them is crap, has not been unit tested, there are not massive build environments or anything, I don't write for reuse until I need to reuse, I acceptance test it myself. My users love the apps. They are bug free and reliable, and users often leave reviews to this effect. Experience is everything. I'm old school now, back in the day live fixes to production data were nothing, no-one would ever do that now. I met older gen devs than me, they did not then and do not now even use source control. Yet their releases were and still are 100% stable and bug free. They are still paid a premium for their thoroughness. As I grow older, I see more value in keeping it simple rather than miring down the work in process and the pressure of doing it perfectly. There is little value in it for the customer if the dev is experienced. And I'm happy that these premium jobs are now coming up for me.

So one thing I don't see a lot of responses calling out, that I think is worth calling out, is what you see is how long the -code- took. You don't see how long the design took. You assume it started when the code did, but that may not actually be the case. These other developers may have had this idea in the back of their mind for months, chewing it over, thinking about how they'd approach something, doing research in their spare time, etc, before finally sitting down to code it. Same with feature extensions; they likely had a feature request, or the idea, and thought about it long before they coded it.

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.

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.

You're not missing anything. It starts out that (code is crap) and you just get better the more stuff you write , and even then you never quite feel like you're writing "good code".

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"

Do you know when some naive people claim that build a "simple CRUD app" is easy, but a OS or a Database engine or a Game engine or Language or Super-Cool-Algo_performace-magnificence or Super-Science-thingy is hard?

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.)

IN CONTRAST

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.

I have a simpler explanation for this feeling- it's just that time of year again. Judging by the other responses it's just on everyone's minds. We can all look back and take stock of what we accomplished throughout the year and feel like we could have done more, could have done it better. When I'm bored I like to window shop cheap used cars on CraigsList. I think to myself "No one sees what I see in this beauty- if it was mine I'd be so happy". Code can be the same way and it seems like if it was yours it would be a new lease on life. The code may be found in the darkest corners of the internet so neglected but so much potential. Recognize in that moment you are creating your "style" your "way" of creating the inspiration which is really the goal. It's not about personal worth it's really about feeling free to create. Developers are their most creative selves when they are happy so...my first suspect in finding the path to developer enlightenment is environmental factors. Development IDE? Workspace area? Skipping breakfast? Look at these things with objective eyes then try to improve them then try again. Merging all of this with financial concerns is going to wire your brain's reward system up for self defeat- gain the freedom first then the money.

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?

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 used to be like you, until I went back to the basics. Elon Musk once said, you must master of the basics, which becomes the foundation of which you build your knowledge. If your foundation is weak, there's going to be hard limits to your knowledge.

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.

Hey tastyface. I feel you. I'm here. I didn't graduate from college, and my knowledge is ad-hoc, learned-by-doing and incomplete. I told myself I wouldn't give up until I was making a living writing code. I'm doing that, and it's been arduous, but I've never been more intellectually fulfilled.

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.

First, you're comparing two different domains. App developers (whether mobile, web, or some other environment) live at the top of the stack. As such, they must wrangle many disparate frameworks and libraries to achieve their goals. Framework developers can focus on a narrower set of concerns--albeit sometimes quite deep.

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.

I also do iOS apps, and I think the reason for bugs and low maintainability in our domain (i.e. programs that have to power a GUI and all its states) is convoluted state. You stack feature upon feature, and once the system gets big enough, it's getting hard to get a proper grip of what is actually happening. So you start monkey patching, and you start to regret not having written any integration tests that would tell you when you introduce regressions.

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.

> The code is generally messy and horrible, rife with race conditions and barely holding together in parts.

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.

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.

Work with other people. Preferably a mix of people who seem less/equal/more capable than you are, but if you have to pick one, go with working with people that are above your level. Look at how they work, how they approach problems. Get code reviews from them, and review their code.

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."

It is important to realize our current situation before we can upgrade yourself, so it is good you know that and are willing to do that.

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.

Write more code. Learn different languages. Reinvent wheels. Stop following the herd. Most of the people who's code you're admiring have been blazing their own trails for decades. There are no short cuts to experience. Good luck!

> Over the past 3 years, I've released a few apps on iOS: not bad, nothing that would amaze anyone here. The code is generally messy and horrible, rife with race conditions and barely holding together in parts. (Biggest: 30k LOC.) While I'm proud of my work especially design-wise I feel most of my time was spent on battling stupid bugs. I haven't gained any specialist knowledge just bloggable API experience. There's nothing I could write a book about.

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.

- 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.

First off, you can spend a lot of time adding amazing features that are never used.

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.

Coding ability wise, elite coders are usually already well above the average professional senior programmer level while still in their teens (emphasis on coding ability wise).

But,

- 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).

There is lots of good advice in this thread. I would like to focus on your comment about race conditions. It's very good that you have identified this weakness in your code. Writing concurrent code is hard, but it's also valuable experience because there is no room for shortcuts. If you don't do it right, your code will fail eventually. Therefore writing concurrent code, identifying bugs, and fixing them will train you to think rigorously about your code.

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.

Maybe you need to get yourself into an environment where there are other people around who can critique your work, and from whom you can learn better habits through observation. This may work better in an environment where you are in physical proximity with co-workers, i.e., a traditional software shop kind of job. Even if this kind of work isn't your ultimate dream.

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.

It's all a matter of perspective but if you want to work on it, these things can be learned.

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.

Judging from what you said. You need to learn to read the language rather than simply understanding the syntax. You need to understand what is going on under the hood.

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.

>> Major features were added over the course of weeks!>> to say nothing of getting the overall architecture right from the start.

[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.

There are no shortcuts to "supercharging" your work. Git gud, bro. Put in the effort. When you see exemplary code, study the principles behind it and seek to emulate it. I'm a better C programmer now than I was, for instance, because I read a lot of BSD source.

Some time ago I worked porting software. The software we ported was very successful financially. It also looked very polished from a user perspective.

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.

If you want to become a domain expert, become a domain expert. You won't learn the intricacies of the newest structure from motion algorithms by writing user-facing apps. you have to specialize, possibly for years, until the domain is second nature and the code is just putting your knowledge into text, if you want to singlehandedly write a world-class library.

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?

You should do some data analysis on where you are spending most of your time when building software and see if there is a way to do it faster. You can read books and follow someone's advice but nothing can be more useful to yourself than trying to navigate your own mind space in search of answers that you are looking for. If you figure out that you are spending most of your time deliberating how to name variables, you should spend time reading about programming styles. If you spend time debugging, identify what sort of bugs you are creating and try to go over books that cover most common programming bugs and try to incorporate them during programming time itself.

Before you compare your work to that of others you really need to know how much time was spent on both and normalize accordingly.

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.

The secret is to use good libraries and especially good languages. That you were chasing race conditions at all implies that you were programming at far too low a level (unless you really did need some super-tuned thing, which it sounds like you didn't).

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.

Actually typing code doesn't take much time. Understanding the problem is the difficult bit.

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.

> The code is generally messy and horrible, rife with race conditions and barely holding together in parts.

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.

I'll be 35 next year and started writing code when I was 30. I have very similar experience. This year, I focused on how to write better code instead of designing and building. I'm slowly getting better this year. My biggest code base for one of my prototype was around 25k LOC. I mainly wrote iOS app, too. I spent more than one year to take care of my kids so there was a long gap. And it has been difficult for me to find a job. There are always meaningful ideas and having the ability to bring some of them to life is my biggest motivation.

At least when you talk about reviewing code that "someone wrote in a month", note that a quick `rm -rf .git; git init; git add *; git commit` works wonders for others' perception of how quickly you can produce code. :)

I think the first few years of programming are the most difficult. You have to go through this process of building and throwing away. Only with that experience you learn to anticipate things should be put together. That makes thing go more quickly.

this rings as very fake and/or blatantly self-promotional. I wish HN had less of this type of post. I feel like a certain percentage of HN posters have learned how to push enough of the buttons of the rest of you to make it a net win for them. just nauseating.

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 :)

Programming is a practice that can be kind of deceptive in its valuation. To analogize to weightlifting, one of my favorite things to analogize against, you can see that someone lifted a lot, and you see that they did in fact lift it all by themselves, but you don't see how they get to that point, and you can't simply put on the same number of plates on the bar and hope to succeed.

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.

* Some people will be hostile to you or your ideas. Maybe it will be personal, maybe not - but people can be ass-hats, so expect it. Don't waste a lot of energy on people who have no interest in exploring new ideas simply because they didn't come up with them.

Thou shall not work in a company where there is no career path/1o1s/generally good management.In the interview ask how to verify what is being offered.Thou shall not never ever work overtime unless it is clearly appreciated and/or compensated.

See that Senior Engineer over there with the white hair, dorky glasses and a shirt begging for a pocket protector? Attach yourself to him and listen. You'll learn more from him in ten minutes than you will in ten hours of conversation with your classmates-cum-coworkers.

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.

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[0] 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...

Getting quickly to my position would be a frustrating proposition. A considerable portion of how I got where I am is because of the mistakes I made. I wouldn't want to have gotten here faster and the pursuit of getting to "senior" faster isn't the right mindset.

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.

It doesn't have to be perfect. It just has to make sense for the business, even if it means skipping things that you deem necessary for a perfectly-engineered product.

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.

I don't consider myself a senior developer, but this is what I'd tell my younger self:

- 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!

There are so many things, of course. But here are two things I wish I'd understood better a long time ago:

* 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.

Don't spend so much time coasting in jobs you're not really interested in, because you think it's the best you can do, and it pays well. The years go by fast. Be dogged about building skills in areas of real interest, getting into that sector, and meeting people who are focused on similar things.

Don't let imposter syndrome hold you back - it's not bad to check yourself, and imposter syndrome can certainly help you as well - but when it prevents you from even trying to get ahead, it can delay your career trajectory significantly. Be confident in what you do know.

What makes someone a senior developer is that they reliably reduce technical risk to a project and deliver on time. There are a lot of definitions for "senior" floating around, but that's what everybody really wants.

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.

This is not "Data Science" specific, but bootstrapping a client base for a new company with no street cred is done nearly exclusively through networking, e.g. you would start by aggressively asking your contacts for referrals, poaching clients that you've previously worked with, etc.

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.

Not specifically Data Science but I've had individual success directly writing to people (in companies) who are working in the area.

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.

Identify potential clients. Go out and introduce yourself and your company. Ask intelligent questions about their business. Listen to their answers. Thank them for their time.

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.

I think data science is a little different from other consulting jobs.

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.

If your interested in developing a name then content marketing is the game.

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.

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.

There are people with all kinds of experience level, someone would definitely find it useful.

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).

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.

I would definitely be interested if you threw Electron in as well. I would pay $20-$30 for an ebook on that as I'm struggling with getting React to work with Electron and all the tutorials have their stuff just work and it doesn't work for me when copying what they have. It is beyond frustrating!

I would love to read this if you published it! I would pay for something that was really well written (gauged off of sample chapters). I would probably only pay around $5 for it.

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.

Yes--absolutely. There are a lot of video tutorials for React, but it feels that there's a lack of written guides at the moment. Not everyone learns best from videos, so having more choices to learn is huge. You should go for it.

NodeJS is generally not an appropriate backend choice given the dynamic nature of the language. I would not be interested and would hope that it comes with warnings that such development stacks are usually only appropriate for small projects if at all.

You can still stand on the shoulders of others when you are a solo developer. That might sound obvious, but you can offload an enormous amount of brain-power to the work of others due to the neural nature of the net. I consider the net my 'exobrain' and it's worth learning how to get answers rapidly using multiple different search engines. Google is handy, but it's worth investigating the native search capabilities of other sites.

One obvious search mechanism is, of course, Stack Overflow. HN's Algolia search is another. Personally I run Searx[1] locally and permanently have it open when coding.

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.

For all the reasons listed, and because working alone means there is no one with which to share the misery when things don't go well, the objective best practice is probably to find another developer to work with.

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.

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.

It's not clear if you're asking about solo developer or "solo company" as it were. Anyway, typically if you're doing a startup the advice is to get a partner. Then maybe you're not so solo anymore. If that's not possible, then expect to spend lotsa time on marketing instead of coding :)

I am working Solo, but I get to bounce ideas off my spouse who also works in IT though it is sporadic at best. I am proactively trying to do this more, as it helps to air my ideas and it is much easier to recognize rabbit holes.

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.

sounds like the real reason is that someone's not pulling their weight. the question becomes, was this person pulling his/her weight before this family affair? i'm assuming this was a random, sudden change or was the mother sick, for example, during a long stretch and recently succumbed? what i'm guessing is that this was a long battle, the latter, and that he hasn't been himself for a long time. if you value his potential or previous contributions then put him on extended leave, even if he doesn't want to, and then deal with it by pushing harder or hiring people. if you're just using this recent development as a trigger then i think it's a bit more involved and you probably are regretful of having him in the first place, regardless of this most recent change or not, but perhaps dealing with some guilt due to the recent passing of his mother.

Is there anybody on here who has successfully dealt with depressed employees/co-founders?

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.

I'm not an experienced manager or anyone to give advice thereof, but I have experienced what your co-founder is currently going through. Last Year in January, my father passed away and the next 8-9 months were miserable for me. Sleeplessness, anxiety and depression were almost feeding to each other and took a toll on me. I could hardly sleep for an hour at night for consecutive weeks and months at a time.

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.

Grandpa Fred was my beloved's grandpa. In 1998, we were out in Iowa visiting the extended relatives on that side of the family and did a video interview life review...on video tape. Grandpa Fred was born in 1912. We asked him about his life. The first thing he said at age 86 was that his mother died when he was twelve and "after that there was no picnic". It had been 74 years. He'd buried a wife. And a son. And in his mind the death of his mother was the defining event in his life.

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.

Your story sounds similar to something that once happened at Valve. Gabe Newell offered a sick employee an extended leave with pay and told him, "your job is to get better." I believe he's still with the company.

You say that you want him to "take some time off" but then mention that he is "often absent". This to me signals a much greater issue. I think if you were to remove him from your team it would be a huge mistake. We are people, not machines. Sometimes we go through hard times. You need to build a company that supports it's people during these difficult times not abandon them in their time of need. Talk to him and let him know you are there to support him.

Have you already had an open and honest discussion with him outlining the above? Presumably you have evidence of his decreased productivity so that it's not a subjective point of view. What is his response when you tell him that he's been absent and not productive when present? Maybe he doesn't want time off, but he needs to come up with a plan with you guys that has him returning to regular productivity.

Define the separation between your personal and professional life clearly. It's not a shitty thing to do.

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.

I think that next time you talk to him, instead of "suggesting" that he take some time off, you have to clarify that it is not a suggestion, but a business partner request, and a "no" will not be looked upon kindly.

> If an applicant takes the time to apply to your posting, why not give them a follow up regardless?

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.

I was recently laid off so I'm on the job hunt. I applied to Snap, Inc and received this response within 2 weeks of applying

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.

What kind of reply would you want? Would a simple "no thanks" be enough?

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 get 200+ responses to most job postings. 90% or more of those are from candidates that just spam every job ad on the internet with their CV even if they live on the other side of the planet. We can't respond to each of those.

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'.

Pro tip: If you want a reply to your application, try to avoid cold emailing hiring managers your resume. Often my inbox has a lot happening, and I'm not inclined to spend time copying your resume into our hiring software unless there is something spectacular about your email or background. Emailing hiring managers out of the blue also will not help you bypass any steps in the hiring process.

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.

We have several people that apply for every job we post (and there are hundreds per year). On top of that we receive resumes that clearly have nothing to do with the position as well as cover letters that have the job title wrong. Some attach these materials without actually filling out the online application.

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 received 155 resumes for the last postion I posted it would be too time consuming to reply to every single one. However I always contact all candidates by phone that came in for an interview to let them know we have chosen not to pursue them for the position.

This is probably bad practice, and I don't hire much anymore, but when I did, I could usually put the resumes in three slots:1/ Good match, want to see2/ Maybe3/ No

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 I were using a system where rejecting a candidate was a one-click operation, and it also sent them a notification, I would click it. That's what it would take--it would have to be that easy. There are too many resumes.

(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.

Many applications that we get do not meet the key requirements from the job posting and are very generic. If the applicant did not put any effort into the application - why should I? Maybe this process can be automated with some ML/NLP to check if the application (a) matches at least SOME requirements and (b) is not too generic but actually hand written to match your posting and company.

That works for automated systems, where you get an automated response. But hiring managers are busy, have multiple processes with HR, and with the rise of job sites end up getting hundreds of resumes, most of which are completely irrelevant, since it's so easy to blast our resume across the Internet.

I'm still happy with KeePass. Currently using one of my cloud-drive folders to manage my password files (at this point I have some context-specific side files), but debating switching over to a Resilio Sync share (possibly an encrypted share with a "know nothing" backup node in the cloud somewhere).

1Password. Can run 100% local(how I run it). It is Commercial, but on a Mac, especially with tools like https://github.com/ravenac95/sudolikeaboss , it's totally the best there is, integration wise, and speeds up productivity an amazing amount while staying pretty secure.

I love pass (password store.org), which generates and files your password as a gpg encrypted file in a folder tree, is scalable to have the file decrypted by different gpg keys, comes with hit support, and a android app is available (fdroid) that integrates with openkeychain and yubikeys and fidesmo cards. Perfect.

I'm fond of pwsafe. Runs on Mac and IOS and shares file in cloud. Like that it is not browser based (though they do have an optional browser plug-in). Excellent for storing hundreds of passwords and security entries. https://pwsafe.info/

I strongly believe that everyone could write useful, nontrivial programs:

- 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.

At my college, CS 101 was an intro to the C language and it was required for all engineering students, not just comp sci majors. I tutored a lot of guys on my dorm floor so they could pass it, but most of them couldn't wrap their heads around any of it. Not even FizzBuzz. And these aren't stupid people, either. Most of them went on to do well in aeronautical and civil engineering disciplines.

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.

Of course. Just as not everybody is cut out to be an athlete or a musician, not everybody has the abilities to make them a (semi-)competent programmer.

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.

The problem is that many people drop out of high school or college without getting the required math and computer classes to understand how they work. Some people don't study computer science at all but want to get rich quick.

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.

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 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.

The job market right now is pretty brutal. If you can keep your current job, do it and if you have time try to contribute to an open source web project like django. If you can become a django contributor even for small bugs that will set you apart in a very crowded job market. Personally I was forced to take a brutal 75% income cut just to not go on unemployment in California and become homeless, here there is really no safety net. I've managed to stay in the game for 25 years but its not at all easy.

I like to dig in deeper about how computers and software works. It is fun, I learn a lot and it have given me many jobs even without an exam. You could learn more about Linux, UNIX, cloud services, http etc. I don't know how the job market for Windows based desktop applications will be in the future.

You need to market yourself. Get a website, cards, handout, anything, then go to meetups. Talk to your local sbdc rep. Craigslist ads work well. Contact me and i'd be happy to tell you all the stuff i do.

I used to work for a company Zillabyte that had a lot of web data. Mostly marketers and sales people were looking for lead generation. Let's say you work for Mixpanel, and you want to know all the websites out there with Kissmetrics installed. Even better, a report every month showing who uninstalled their analytics tools. Others looked for more general signals than javascript snippets (weak text analysis), but that was the bulk of what people asked me for.

This is all great to write down as to what it could eventually become.. I think it has to be chunked to more manageable units, first. I mean, whether you have the individual skills required or not, it'll start by requesting a page and inevitably forgetting to show the respect Unicode deserves.

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.

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).

I work in a blockchain company and I'm building a tool that allows users to vote on pull requests to be merged to github, all done on the blockchain.

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.

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.

I direct my imagination into another channel. I think about what stakes each stakeholder holds and imagine what the project looks like from their perspective. Then I ask questions that tune my imagined perspective to their perspective and questions that help me address what is important from their perspective.

I'd say perl, but you could debate whether "ignored" really describes it. Something in that neighborhood (perhaps under-appreciated) does. I see people doing a lot of ugly shell pipelines and contortions with sed, awk, and bash that perl can do easier. Perl runs everywhere, usually already installed along sed/awk and friends, runs comparatively fast for a dynamic scripting language, has great documentation, and chews up and spits out the problem domain of sed, awk, and bash. It has the same command line switches on OS X, Linux, BSD, and even Windows.

My suggestion is maybe not a tool that is ignored, but vast majority of itsoptions: /bin/ps from procps (Linux-specific).

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.