This is a follow-up to my Friday rant Forbes is wrong about "Developernomics"
First: If the subject's of interest to you, you might enjoy (or despise) the column on the subject I've been writing for SD Times for the past decade. (I can't help but wonder if I wrote in my normal, less-heated mode if I'd have had any chance of getting picked up by hackernews.)
Luckily, though, this is a subject that really sets me off, so I don't have to manufacture passion. I get angry because the Myth of the Superprogrammer has lots of important consequences:
IF programming excellence is Big O(inherent talent) THEN that should guide developer careers.
IF excellent programmers are 10x median productivity THEN that should guide software team structure.
Organizations will tend to structure their software teams according to the model of development excellence held by senior management.
So I don't think this is a harmless matter of opinion, a "my language is better than yours" bar-room perennial. The Myth of the Superprogrammer affects your career, mine, and that of all of our colleagues.
It's important that I reiterate that I fully understand that arbitrarily-high productivity multiples occur in any number of contexts: from the trivial "I've been working in this language / library / codebase and you haven't" to the complex "this project was rescued." (And since "the project was rescued" implies the uncommon but not rare situation of zero or negative productivity, the advantage is arbitrarily high.) The most interesting context to me, is the situation of "Tim in Colorado", a commenter on my previous post, who was the original architect and implementer of a game engine. It may be that in a situation like that, transferring the mental model, decisions, tweaks, etc. of the codebase is so difficult that he will forever hold that 10x advantage. (Although I'd point out that from an organizational perspective, such a situation is not necessarily wonderful: they have a bus factor of 1, they may trouble freeing up Tim to work on new projects, etc.).
But saying "In some contexts, Adam is 10x more productive than Charlie," is not the Myth of the Superprogrammer. The Myth of the Superprogrammer is "Adam's great advantage over Charlie is driven by an inherent advantage Adam has over Charlie. Adam is rare, Charlie is a commodity."
Let's be clear about what "10 times median productivity" means. It means this:
The claim is an order of magnitude: In one day they produce a sprint's worth of functionality. In a month, they do a year's work. In a year, their contributions oustrips the combined output of nine competent colleagues. They can master a new system library not in 6 months but in 3 weeks, they never walk more than, say, 15 minutes going down a wrong path, they never lose days waiting for an answer from a domain expert, they never lose the work of weeks to a changed or misconstrued requirement. They are The World's Most Interesting Programmer. Except such people not only exist, they're not vanishingly rare! There are lots of them: you should strive to hire such a paragon. Everyone else is hiring them! Why not you?
Whoops, there I go starting to get emotional...
And I'm not being unfair in my characterization of what "10x productivity" means. It has to mean such things, because that's what programming productivity is: delivering value to the customer. It's not writing code or debugging code or refactoring code: those are simply the means.
Sure, way out on the tail end of the distribution of the several million professional developers, there are some flat-out programming geniuses. And maybe if you squeeze down the tail far enough you can find some who combine flat-out programming genius with collaborate-with-users genius. But the Superprogrammer Myth requires a high variance: there have to be enough developers who achieve 10x median productivity so that they regularly make an appearance in industry.
Let's say that's correct. What does this distribution imply?
It implies that hiring is overwhelmingly important, that it is better to be short-handed for long periods of time rather than fill the spot with a person who everyone agrees is clearly better than median. God forbid you hire a person who's only twice as good as median.
It implies that experience with the tools and libraries that your company uses is entirely irrelevant: a 10x-er will pick them up 10x faster than median and going forward, of course, will be 10x more productive with those tools. (To be fair: I do actually believe that "you cannot teach tall" and that "x years with tool y" is a terrible thing in a job requirement. But I also believe that this is a significant trade-off.)
It implies that you should have an enormous variance in your compensation structure. If Charlie is a 10x-er and Adam is median, Adam should be compensated far less; his loss is unimportant to the productivity of the team, while Charlie's retention is utterly critical.
It implies that median salary should be stable or decrease over time, since the abilities of a median or "only" quite good programmer do not drive overall team productivity. Quite good developers can be replaced with a cheaper quite bad programmer, as long as the team has a Superprogrammer whose 10x contribution drowns out such small signals.
It implies that you should structure your team as a Chief Programmer Team: everyone serves the needs of the 10x-er. Keeping the Superprogrammer loaded is the goal of every member. The Superprogrammer ought not to be required to explain or collaborate on important decisions.
It implies that the comings and goings of the Superprogrammer have an enormous impact on the company's productivity: the Superprogrammers arrival coincides with a massive uptick in productivity, the Superprogrammers departure creates a massive loss of productivity until the Superprogrammer is replaced.
Those implications do not describe the industry that I know. They describe a TV show.
Part 3: Moneycode vs. Developernomics