How Programmers can Adapt to Increased Investment in Software

In the last few years there’s been more investment in software companies and more companies investing in software. All of this money pouring into software projects has a lot of implications about what it means for tech companies and founders.1 But I haven’t seen much about what it means for rank and file programmers.

As programmers we spend a lot of time thinking about the next big tech or that hot startup, but rarely about how the market will affect our career. As an individual contributor engineer I wanted to think about what the implications of increased investment in software mean for my career.2

The premise is that there is an increase in investment dollars flowing to software projects and that this investment has been across the spectrum of projects. Examples include:

  • Everyone pouring money into FAANG stocks,
  • Large investment in Unicorns (think Softbank investing in every private tech company)3,
  • The explosion of VC firms
  • Every company investing in software
  • Funds like Tinyseed investing in single founders SaaS companies

The other premise is that the rate that investing is happening is faster than the rate that new programmers are joining the profession4

Primary Effects

Continued high demand for programmers.

This is the most obvious effect but it bears repeating. If there are more investment dollars flowing towards companies and projects that require programmers then the demand for programmers will increase. This means that there will be an increase in the job openings for programmers. Importantly it does not mean that the quality of all programming jobs will improve. Crappy “Office Space”esque jobs will still exist. There’s just less reason to stay there.

More projects at the margin will be funded

With more investing dollars going towards software, projects and companies that otherwise wouldn’t have been funded will be. Intuitively this would mean that we would expect failures of all types to increase. Anectdotally when I poll developers with more than 3 years experience they said somewhere between half and two thirds of projects fail. The Standish Group, which has been tracking this for 25 years finds that 36% of software projects succeed. I wouldn’t be surprised if this number decreases.

Failures can be from execution, fraud (Theranos), competition (MySpace) or a bad business models (

What might counteract the increase in failure rates will be that projects that are marginal from an “investing in software” perspective make perfect “investing in not software” sense. TinySeed invests in remote bootstrapped SaaS founders. That’s not worth the effort to invest in for traditional VC.

Similarly as software project become something more companies invest in it’s likely projects that are below the expected value that a director at a tech company would expect will get funded. Some of these projects will end up being successful even if they would have been considered a ‘failure’ by tech company stands.

More Capital Intense Projects will be funded

Just making software doesn’t take that much investment to create (especially if the founder is writing the code). But as more money goes towards “tech” companies projects that take more capital become possible. Things that involve building an electric car plant or rocketships or wi-fi connected juicer can also get funded. This means that more and more companies will be positioning themselves as ‘tech’ companies even if software isn’t their primary product. The software might just be the thing that enables the product.

Secondary Effects

Capital Deepening

Some of those investment will go to failed startups and overvalued unicorns but some of it will go towards making programmers more productive.

Capital deepening is the process of the amount of capital per worker increasing. As stated above programming is not very capital intense so it could benefit from an increase in capital in the form of better ‘tools’. Some of these will be open source, some closed source and some will be a services. The ‘cloud’ is the best known example of this. It’s usually a better idea to let Amazon, Microsoft or Google run your servers then having your programmers do it. This is both due to expertise and returns to scale. A cloud provider knows more about keeping five nines of up time than you do, and it has entire teams whose full time job it is to do it.

The cloud is just the most apparent example that everyone knows about and most organizations are moving to. But there are libraries and services for all sorts of project that make developers more productive. I recently learned about feature flags as a service. Which might sound unnecessary to many developers. But to build a full featured A/B service takes a large amount of developer time. By outsourcing it to a third party service programmers can focus on the core business problems.

An interesting side effect of this is that it makes programmers and capital more substituable.

Problems that you previously had to spend programmer hours on you can now just throw money at.

This is a trend that will countervail the increased demand for programmers as some of those programmers can be replaced by using libraries and SaaS instead. This will mainly impact internal tools or projects that are not a core product or one of your companies core competencies. Things that could be outsourced to a library or SaaS. An example would be using Travis or Jenkins instead of building your own Continuous Integration system. Overall this will make programmers more productive.

Software projects more likely to fail, faster and smaller

It’s hard to believe the 36% success rate could get worse but it is likely to. With more companies and projects getting funded at the margin you will see more competition and more projects ending in failure. In addition the increase in non-software companies doing software projects also means there will be an increase in failed projects (Assuming that software companies aren’t worse at managing software projects than non-software companies. Having tried Waterfall and Agile I’m open to counter arguments but it seems correct prima facie.)

The percentage of failing projects will increase but the number of programmers on failing project will decrease

The better tools will mean that a smaller team of programmers can finish the same project in a shorter period of time irrespective of if it fails or succeeds. A project that previously took 5 programmers a year to ship (60 programmer months) might only take 4 programmers 9 months (36 months). If the project succeeds those programmers might continue to work on the project but if it fails they can switch to another project.

The increase demand for programmers also plays a role here. No one likes to work on a failing project. It is especially frustrating if you have successive failures that are caused by reasons outside your control or if you predicted the project would fail and still had to work on it. With programmers in high demand they can respond to failing projects by switching companies or switching teams if the company is large enough.

Companies stay private and independent longer

This only really applies to late stage start ups, those past the point of crashing and burning but not yet acquired or gone public. These companies are more likely to be able to stay private and independant longer due to it being easier to raise additional capital from the private markets5. This means a longer time (if ever) before stock (options) becomes valuable.

What this means for programmers

Charge more

The continued high demand for programmers combined with the capital deepening that will increase programmer productivity means that you as a programmer can make more money. Dan Luu has an article exploring why programmer salaries are bi-modal6. The article is a fascinating discussion of why this is but the takeaway is that you want to be on the right hand side of that distribution.

If you’re working at a low paying programming job you are going to have switch jobs to get a pay raise

It’s difficult to impossible for companies to change how they compensate people. This means if you want to be in the higher paid part of the distribution you probably need to switch jobs. It doesn’t need to be to a FAANG company as long as it’s TOOTHY (Technical Organization, Overall compensation Two Hundred thousand yearly)7. From recruiter emails I get this includes banks, late stage start ups and any job posting that has the words “machine learning”.

Interviewing suck. The best advice I can give you is work through Programming Interviews Exposed and if you have the time Cracking the Coding Interview, go to a lot of interviews and don’t expect to pass your first one. Once you get to the negotiation stage read this article by Patrick McKenzie8.

Feel free to email me if you have questions specific to your situation as I previousy worked at a terrible government contractor job before escaping and might be able to offer advice.

If working for a private company your time frame until they go public/get acquired will be longer as the firm can afford to stay private longer. This means any stock you have will take longer to become cash. In addition with the increased likelihood of project/companies failing there is an increased chance that their value is $0.9 This is something you should consider when thinking about whether you want to work at a startup, where a significant chunk of the compensation is options or stock you cannot sell, or an established company. There other pros and cons of working at either that you should consider 10.


As a wider array of companies build software, to increase our productivity and succeed programmers will have to specialize. The capital deepening in software tools will also feed into this trend. Specializing means that you have time to master the tools you need to quickly finish products. It also means that you are familiar enough with the domain to know what the possible space of solutions are and don’t have to spend as much time getting up to speed. The first time I had to reverse engineer something I had to learn what the Interactive Dissambler was and how to use it. By the fifth time I had to reverse engineer something it only took me a few hours.

As someone who enjoys changing what I work on regularly this trend bothers me.

An important caveat is that you don’t want to specialize too much as that makes employment harder. So don’t be a web developer who only use Ruby on Rails or a data scientist who only does TensorFlow. For web developers a clear example of this is that Google Trends for back end developer is flat while full stack developer is up. It’s hard to know what the ‘right’ level of specialization is, my best guess is job postings will be for jobs such as:

  • embedded programmer
  • database administrator
  • systems programmer
  • web developer
  • desktop application developer
  • data scientist
  • mobile developer
  • back office programmer

Another implication of this is the increased importance of working on the core product wherever you work. The increased capital deepening means that companies are more likely to try to use third party tools instead of a full time developer wherever possible. So it’s important that whatever you specialize in a core product that the company does not want to outsource.

Consider a wider range of jobs and cities

As more software projects are funded by non-software companies and more software companies move into other industries a wider set of companies become viable options paying a comparable wage to traditional tech/banking companies in traditional tech/banking cities. If you’re in it strictly for the paycheck you will probably want to stay traditional. But if you want to work at a non-tech company or don’t want to move from a city that isn’t a tech hub that’s becoming less of a problem. Especially as more companies open satellite offices and remote work becomes more common.


The major trends if there continues to be increased investment in software are that the demand for programmers will stay high, the percentage of marginal projects will increase and more capital intense companies will get funded. This will lead to better tools, a higher percentage of failed projects and companies will stay private longer. As a programmer this means you should charge more, specialize and look at a wider spectrum of projects/locations. Obviously you might disagree with these conclusions but if you’re smart enough to learn to program it’s worth spending a few hours to sit down and think about what you think the landscape will look like for the next few years.

  1. Matt Levine covers this issue regularly. To simplify founders of companies are finding it easier to keep control of their companies because more investment dollars are competing with each other e.g. how the founders of Snapchat still control their company even after going public. 

  2. I was inspired by Tyler Cowen’s Stubborn Attachments specifically “We should choose the course that is most likely to be be correct, keeping in mind that at the end of the day we are still more likely to be wrong than right.” and “I’m a skeptic, sure but I’m a skeptic with a can-do temperament who realizes how paralyzing skepticism can be” 

  3. Again Matt Levine covers this in beat if your interested in the gory details. 

  4. I’m basing this off a comment by the founder of Lambda School, who’s essentially betting the company on this fact. 

  5. Simply search Matt Levine public is the new private 

  6. The bimodal distribution doesn’t seem to me to have a single clear cause. 

  7. This might sound high but that average salary of a programmer is pushing 100k. Add in bonuses, healthcare, 401k match and the fact that you’re not aiming for average and 200k isn’t crazy. 

  8. In general all of his career advice is spot on so it’s worth reading. 

  9. Dan Luu has a clear headed article on how to think about options. Having walked away from options that were “worth” $30,000 I strongly advise reading it. 

  10. Again Dan Luu has an article talking about these tradeoffs. My tl;dr is the money is better at big companies and which is more interesting depends on your team and interests.