I think it's simply that code written to be 25x cleaner, shorter, and faster, will not bring 25x the revenue to the company. Coding skill is only one factor in the ultimate fate of a product.

A company I worked at has this business model where they recruit extremely cheap interns (mostly from France) and have them develop products. In their eyes it's not profitable to pay more for a better coder, since the quality of the final product doesn't have much impact on their bottom line; they sell to big business so there's no review site rating their products and clients don't talk to each other.

You can also be a 25x developer and have net-negative product designers and biz dev people on your team that completely negate or at least greatly attenuate the value you contribute.

Besides people, you also have the value of the solution as well. A top developer creator an overkill solution for a trivial problem doesn't create much value either. The value of a solution is proportional to the cost of the problem.

gahhhhhhhhh... I hate autocorrect. It results in typos that make you look like a non-native writer in the language and produces more interference in the mind of the reader, not less, because it's easier to read over a simple typo than incorrect diction.

"A top developer creator an overkill solution..." would have read better had whatever typo that had lead to "creator" instead of "creating" had remained in my original text.

At least red underlines instead of autocorrect highlights the error and prompts you to go back and choose the correct word (<-- perfect example... while writing this previous sentence, "word" originally had a typo and was changed to "work")

This is so true. A "top" developer can often be a terrible development lead or software architect. Often because they try and build generic solutions to specific problems.

This is a massive problem in the Java space where you have these design pattern driven designs that are infinitely flexible but ridiculously complex.

I don't think that's the right way to look at it.

If we go by simple math, developers who are 25x better/faster can launch a new product in 2 weeks instead of a year. That can make the difference between owning an entire market and not even being a participant.

Or you can take a team of 75 developers and instead use only 3. The overhead and cost and difficulty of coordination and communcation between 75 developers can just be too much for a project to succeed, but with only 3 amazing developers it becomes easy.

Also, software projects tend to reach points where they become overly complex or unmaintainable. Developers who are 25x better prevent that from happening, keeping everything working smoothly.

So it's not about bringing 25x revenue. It's about bringing revenue period, or maintaining competitiveness to continue that revenue.

"Also, software projects tend to reach points where they become overly complex or unmaintainable. Developers who are 25x better prevent that from happening, keeping everything working smoothly."

Actually, I think this is the heart of the issue in the productivity debate - I view my biggest challenge as writing code/architecture that can be maintained, easily debugged, etc, my devs (or future devs) are as a constituency for my software as well as my users.

But this is, in a big org, extremely hard to monetize, as disasters/chronic bleed avoided are not even entered into the balance sheet.

I'm pretty sure you can find a 25x spread in developer compensation at Google, and that's within a pool of great developers. But they are an exception. In general, the skill difference is too hard to quantify, and the pay disparity would cause political problems. If you think you're a 25xer the best way to capture the extra value you create might be to join or start a startup.

This is actually the conclusion I came to a long time ago and have been acting on it since. Still haven't captured that value, but it has been fun trying & haven't given up yet.

It was bad enough listening to this myth when it was 10x. Now it's up to 25x. Gimme a break. When you figure out how to measure programmer productivity, then you have the right to put a precise number on it. Not before.

Edit: I mean 'you' in the general sense. Not you personally.

Actually, though I can't footnote it, the meme in the early 90's being pushed by Gates & Simonyi at M'soft was 100:1 or so "orders of magnitude" iirc correctly, so actually, Jobs is a downward estimate from that.

Valve probably has the best system I've heard of for capturing this value. Each employee is peer reviewed on their value to the company and then their score gives them a relative rank in the company. That rank determines their pay. I don't know what the scale is like, but I know Valve has profit sharing to some degree, so I bet it's pretty good if you're at the top of the list.

So you have a source for this? It sounds equal parts insane and amazing. Certainly adds to the Valve mythos though.

This sounds dreadful to me.

Your peers will judge you based on THEIR ability and knowledge. Which in the IT industry is a problem because most developers are overly confident about their abilities. So you will end up with good developers being given poorer rankings.

I much prefer developers being judged on their ability to meet business outcomes.