The most productive programmers are orders of magnitude more productive than average programmers. But salaries usually fall within a fairly small range in any company. Even across the entire profession, salaries don’t vary that much. If some programmers are 10x more productive than others, why aren’t they paid 10x as much?
Joel Spolsky gave a couple answers to this question in his most recent podcast. First, programmer productivity varies tremendously across the profession, but it may not vary so much within a given company. Someone who is 10x more productive than his colleagues is likely to leave, either to work with other very talented programmers or to start his own business. Second, extreme productivity may not be obvious. This post elaborates on this second reason.
How can someone be 10x more productive than his peers without being noticed? In some professions such a difference would be obvious. A salesman who sells 10x as much as his peers will be noticed, and compensated accordingly. Sales are easy to measure, and some salesmen make orders of magnitude more money than others. If a bricklayer were 10x more productive than his peers this would be obvious too, but it doesn’t happen: the best bricklayers cannot lay 10x as much brick as average bricklayers. Software output cannot be measured as easily as dollars or bricks. The best programmers do not necessarily write 10x as many lines of code and they certainly do not work 10x longer hours.
Programmers are most effective when they avoid writing code. They may realize the problem they’re being asked to solve doesn’t need to be solved, that the client doesn’t actually want what they’re asking for. They may know where to find reusable or re-editable code that solves their problem. They may cheat. But just when they are being their most productive, nobody says “Wow! You were just 100x more productive than if you’d done this the hard way. You deserve a raise.” At best they say “Good idea!” and go on. It may take a while to realize that someone routinely comes up with such time-saving insights. Or to put it negatively, it may take a long time to realize that others are programming with sound and fury but producing nothing.
The romantic image of an über-programmer is someone who fires up Emacs, types like a machine gun, and delivers a flawless final product from scratch. A more accurate image would be someone who stares quietly into space for a few minutes and then says “Hmm. I think I’ve seen something like this before.”
108 thoughts on “Why programmers are not paid in proportion to their productivity”
It may be “hard to define” a productive programmer, but many of us know it when we see it. One difficulty, is that those who possess a lower level of talent and technical insight are sometimes unable to correctly evaluate the relative productivity, or value, of the highest performers. As Sir Arthur Conan Doyle put it: “Mediocrity knows nothing higher than itself. Talent instantly recognizes genius.”
Reminds me of a great post by an ex-colleague that illustrates what you say: http://www.uncarved.com/blog/pay_by_results.mrk
Now that you’re working for yourself this should no longer be a problem.
(I think I pointed before that self-employed EEUUses have 5 times the wealth of salaried. The chart in the above indicates it’s probably people like you who drive up that number.)
I remember adding color support to a formerly black and white printing application – and getting rid of gobs of code.
It turned out that one heavily used subroutine could be replaced by a simple character constant.
There was not a single failure after release to the customers.
Got downsized anyway.
Productivity CAN be measured. Most software teams use some variation of agile/scrum where they measure tasks based on points. If you’re completing 10x more points than your teammates you are 10x more productive than they are. But, even though this can be measured, companies still don’t recognize people who are great performers.
The same way top tier programmers do amazing efficient work, lower tier programmers can be awfully destructive, to the point that their contributions can be balance-negative and leave lots of complex knots for their peers to untangle or work around of.
In many cases no hire can be much better than a bad hire.
Also note that its hard to find the gems in the haystack and large tech companies just hire a bunch hoping to strike gold. In silicon valey top level ICs can make up to 10x entry level positions
Reminds me of the story about Bill Atkinson at Apple being directed to report on lines of code, where he filled in -2000: http://www.computerhistory.org/atchm/macpaint-and-quickdraw-source-code/
Also relevant, the “Feynman Algorithm”: http://wiki.c2.com/?FeynmanAlgorithm
1. Write down the problem.
2. Think real hard.
3. Write down the solution.
I’m gonna be so thrilled if I ever become a 1x programmer.