5 ms·
This is actually a great argument in support of OP's conclusion. Once starting a software-based business achieves a sufficiently high cost to entry (at some poi
by tspike 7y ago
This is actually a great argument in support of OP's conclusion. Once starting a software-based business achieves a sufficiently high cost to entry (at some point most of the profitable problems to solve will be out of reach of a handful of programmers), I would expect pay rates to plummet.
- NeverFade 7y agoFirst of all, the fact that any SWE you don't employ can start their own business, is just a boosting factor to SWE wage. The key reason companies can and do pay SWEs relatively well is that these SWEs generate large profits for them. That's the "opportunity cost" GP mentioned: yes, you'd have to pay the SWE $400k, but the cost of not employing them is several times that in lost profit. Moreover, I'm not really seeing how the barrier of entry is going to increase substantially. In fact, it will probably decrease. As software eats the world, there will be more and more "pure software" work, which means your only toolset is your knowledge. SWEs with large amounts of specialized knowledge and skills will increasingly be able to compete in these areas (security is a pretty good example). It doesn't have to be your typical company with a logo, brand, and office space - we're talking about consultancies and virtual businesses.
- chiph 7y agoThe places I've worked have had revenue-per-employee in the $200-300k range. That's total employees, not just developers (so, sales, accounting, HR, as well). Doing some rough math, it's been more like $15-25mm per developer.
- NeverFade 7y agoYes, it's the same for FAANG as well. If you just divide total revenue by total headcount, you already get seven figure numbers. But if you divide revenue by the engineers who generate it, you get a big multiple of that.
- rev_null 7y agoIf you divide the total revenue by the number of HR employees, you will also get a much larger number. (Total revenue / total number of employees) will always be less than (total revenue / subset of employees). This is not a very good metric.
- NeverFade 7y agoIn a company like Facebook, who is directly responsible for the revenue? And who is working support roles? If you laid off 90% of HR, how will that affect revenue? What about laying off 90% of the engineers?
- chiph 7y agoHR, Accounting, etc. aren't directly revenue-producing. You could make a good argument that Sales headcount should be included, though.
- yibg 7y agoDivide by number of product managers then, even higher per headcount.
- JoshuaDavid 7y agoI think the surface area of "problems that are possible to solve with a handful of programmers" is so that enormous that even if the capabilities of a handful of programmers stagnated, it would take decades or more to run out of profitable problems. Additionally, the capabilities of "a handful of programmers" increases over time as the best tooling available gets more capable, so the surface area of what is possible expands* over time as well. * I'd argue that as tools improve, the number of solvable problems of a given value increases exponentially e.g. if you have a capability A and you introduce capability B, you can now do things that require only B or A and B, and if you then introduce capability C, that opens up (C), (A, C), (B, C), and (A, B, C) as new problems that are possible to solve. Edit: For a concrete example, with tools like Stripe you can do payments-related stuff without being an expert in handling credit cards, and with tools like EasyPost likewise for physical mail, and with the combination of the two a single developer can now do any of the things that require either of those individually plus things like taking online payments and managing shipping on the best-cost carrier without any in-house staff and only a couple months of dev work.
- petre 7y agoMost software products must stay relevant, so they need countinous improvement.
- ENOTTY 7y agoI suspect that at least one cost to entry that might be coming down the pike is a legal requirement to design secure and resilient systems / software liability. This might start in sectors deemed “critical infrastructure” but that line is increasingly blurred.