| > Your claim that "no programmer is worth 10x the average" does imply this Those claims are debatable and often true, not always true. As opposed to straw men which aren't even debatable. I've seen less actual 10* engineers and more high-functioning individualistic coders who maintain whole systems on their own, and at some point leave the company (most people change jobs at some point, but in their case it was accompanied by "nobody understands what I do" noises) whereupon it's unmaintainable (in one case, running on their dev machine against explicit instruction with no source or login details). Your company may hit the jackpot and hire a budding Linus Torvalds or John Carmack, but the odds are bad and the guy who thinks he's a rockstar is more likely to be a good coder, but an egotistical person. Lots of actual musician rockstars are assholes too. A well-functioning team is a much better bet. Lottery tickets are a poor investment. I know that trading desks may disagree, but IMHO that's a defect of the stock-market gambling culture that they come from (where someone's guaranteed to beat the market this year. Find them and call them a genius!). I've worked in various tech companies, and that mindset is not universal there. It's not even welcome to me. |
First, not all software engineers actually do commercially work on commercial software -- as a quick example, Con Kolivas, who is an anaesthesiologist by day and kernel hacker in spare time. Others may work on commerical software by themselves, without any external team or management involved; think Colin Percival. I would even wager a guess that some of the best software was created in a non-commercial way, say, Linux kernel -- at least the early versions of it.
Second, the impact any software engineer has on company bottom line is much affected by other aspects of a company. In a symbolic notation, you could say:
Invoking the Amdahl's law -- even if you had a 10x SOFTWARE_DEVELOPER, performance of the whole system will be limited by the other factors. In my limited experience, the RISK_MANAGEMENT (of software development and use) part is the least understood one those days.