---
created_at: '2011-11-16T11:59:24.000Z'
title: Why programmers are not paid in proportion to their productivity (2009)
url: http://www.johndcook.com/blog/2009/12/23/why-programmers-are-not-paid-in-proportion-to-their-productivity
author: ColinWright
points: 122
story_text: ''
comment_text: 
num_comments: 77
story_id: 
story_title: 
story_url: 
parent_id: 
created_at_i: 1321444764
_tags:
- story
- author_ColinWright
- story_3242772
objectID: '3242772'

---
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](http://itc.conversationsnetwork.org/shows/detail4328.html).
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](//www.johndcook.com/blog/2008/05/03/reusable-code-vs-re-editable-code/)
code that solves their problem. They may
[cheat](//www.johndcook.com/blog/2009/03/24/redbelt-problem-solving/).
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](//www.johndcook.com/blog/2008/04/27/one-program-to-rule-them-all/),
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.”

**Related posts**:
