
Why programmers are not paid in proportion to their productivity - imgabe
http://www.johndcook.com/blog/2009/12/23/why-programmers-are-not-paid-in-proportion-to-their-productivity/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+TheEndeavour+%28The+Endeavour%29&utm_content=Google+Reader
======
rdouble
The author has not ever worked with the truly 10x more productive programmers.
Most people do not get the chance to work with these programmers. They do get
paid in proportion to their productivity. There are so many horrible
programmers that you can be mediocre and be 10x more productive than the guy
next to you. Thus you think you're in the 10x crew. But you really aren't.
It's not because you're really that good. It's because the guy next to you is
really that bad.

I thought I was pretty good until I worked with the guy who made Winamp. It
took me a couple weeks to make some enhancements to their add-ons site. It
took him a couple weeks to write his own version of Pro Tools. I made 80
thousand dollars. He made 80 million dollars.

~~~
walkon
"There are so many horrible programmers that you can be mediocre and be 10x
more productive than the guy next to you. Thus you think you're in the 10x
crew. But you really aren't. It's not because you're really that good. It's
because the guy next to you is really that bad."

So someone who is 10x more productive then their coworker isn't actually 10x
more productive because their coworker is so horrible? Isn't "10x more
productive" an explicit measure of productivity relative to the guy(s) next to
you?

~~~
scott_s
He meant in the class of 10x better than the average programmer, which would
include all developers in the world, not just the few you can see.

~~~
joe_the_user
Why would the developers you couldn't see be 10x better than the developers
you can see?

Could there be a dark matter halo of great programmers lurking around the
world's mediocre-programmer-filled corporate cubicals?

~~~
scott_s
I meant "the developers you can see" to imply the people around you. That's a
small sample size, and not representative of the entire world.

~~~
joe_the_user
A small sample size would just imply greater deviation. There's no reason to
assume the programmers outside your sample would be x10 better than those in
your sample.

~~~
scott_s
That only works when you can assume your sample is representative of the
global population. Since people are not evenly distributed according to their
abilities, that assumption will not hold.

~~~
TeHCrAzY
But in a generalisation, you have to generalise.

------
tdavis
My proudest moments as a programmer are those where I manage to develop some
functionality in a week or two that took another team of programmers months or
years to do by using a novel approach or stitching together preexisting code.
Every line of code I write is another I will have to maintain. Sooner or later
it will be a burden. For this reason, I strive to write as few as possible.
The programmers I respect most seem to follow the same pattern.

~~~
ballpark
I feel best when I'm deleting other's code, and accomplishing the same thing
with much less code.

~~~
rpledge
100% agree with this, less code = less maintenance. Very few people truly
understand this and why it's important.

~~~
SapphireSun
In my latest app, I've noticed that I get the greatest highs when I write one
specific function, and then rewrite it to be generic enough to handle four
different elements. Great fun.

------
icefox
Really it comes down to the simple fact that for the most part programmers
happily sign a contract saying they will work X hours for Y money. If they are
'productive' they then can move up in the company and be a manager, but still
for X and Y++. Sales guys are paid in a completely different way, same with
the stock holders (founders etc). It doesn't matter how productive you are,
even if you complete the task in 1 hour and have the rest of the week to do
nothing, you agreed to work 40 so your boss will give you something new to do.

------
raganwald
Show me how to measure productivity and I'll find a way for the 10x more
productive programmer to earn 10x the compensation.

I agree with the OP that the problem here is that it is not easy to measure
productivity.

[http://github.com/raganwald/homoiconic/blob/master/2009-02-1...](http://github.com/raganwald/homoiconic/blob/master/2009-02-12/a_question.md)

~~~
DenisM
Start your own business (even if only a consultancy) and look at your bank
account each day. That's the raw, true measure of productivity.

~~~
raganwald
That is roughly equivalent to saying that the true measure of an employee's
productivity is their salary. What are you measuring?

~~~
nostrademons
It's measuring the amount someone is willing to pay you for your work. By an
economist's definition, that's your output. If you divide your output by
number of hours worked, that's your productivity, again by economist's
definition.

I make no claims as to how useful these definitions are. There's a reason why
economics is called the dismal science. But terms like output and productivity
_do_ have accepted definitions - so yeah, the true measure of an employee's
productivity is _almost_ their salary. (It's actually revenue / employee /
hour, so if an employer keeps most of the money as profit, it's still
productivity. That's why the grandparent suggested "start your own
consultancy".)

~~~
raganwald
You make good points. However... if we accept the economist's definition of
productivity, then the article becomes a NOOP: We measure the marketplace, we
discover that given a set of programmers with roughly the same conditions,
there isn't a 10x disparity in output divided by hours worked, therefore no
programmer is 10x more productive.

The only way there is something to discuss is when we presume there is another
measure of programmer productivity and then ask why the marketplace is so
inefficient that economic productivity does not correlate with programmer
productivity.

~~~
nostrademons
I think that there is easily a 10x disparity in output divided by hours
worked. Why did the Etherpads just make 8 figures over the past 3 years, while
I made only 6 figures? They certainly didn't work 100x more. By the
economist's definition, they were easily 100x more productive.

I think that there's a more interesting question in the article - why do
salaries "flatten out" the productivity curve, so that programmers who would
easily be making 100x more as startup founders are instead making 50% more,
with the balance going to the employer? After all, if we measure by revenue
generated for the employer, I'm in at least the 7 figures, within an order of
magnitude. And I doubt Aaron etc. were making all that much in salary when
they were Google employees either.

I suspect the answer to this has to do with risk allocation. Because
technology markets tend to be winner-take-all, there's a lot of variance in
productivity that's _not_ the result of the coder's actions. In other words,
it comes down to luck, being in the right market with the right product. You
can work hard at the wrong thing and still produce nothing of value, despite
being smart and dedicated.

When you sign on as an employee, your employer agrees to take on the risk that
you'll work hard and still nothing will come of it. And in return, they get
nearly all of the upside if your hard work _does_ result in something great.

I suspect that the 10x more productive figure is a result of sample bias: when
you look at what people _have done_ , there are some folks whose projects were
10x more useful than what other people have done. All the people who worked
equally hard and produced equally large amounts of code are lumped into the
"not productive" category, because in hindsight, their projects weren't all
that useful. If you try to predict, a priori, who the 10x coders are, I bet
you'll have a much harder time. If you don't, you have a sterling future ahead
of you as a venture capitalist.

~~~
cellis
This is one of the best posts I've read in a long time. It is easy to forget
that, with regard to creating _wealth_ , there are lot more factors at work
than raw programming skill.

Networking, for instance, can greatly increase your output if you choose an
awesome cofounder. It has a benefit that is not easily defined because of how
hard it is to decouple the work and effect of each individual team member.

I know of one person that is worth easily in the 8 figures range, but he got
in early to the venture. This does _not_ mean he's a better programmer than
everyone else, but he does benefit from a lot of factors that sum to being
more important than programming skills.

------
motters
Being super-productive isn't always wise for the black belt coder. In the
traditional world of commercial programming if you solve the problem in a
couple of hours and then just spend the rest of the day fooling around,
reading scholarpedia or working on your own pet projects managers often don't
look upon this kind of behavior favourably - they think you're not being
productive, when in fact the opposite is the case.

From having spent most of my adult life in the world of software development
I've noticed that it's the programmers who make a lot of noise, huff and puff,
and spend all day battering a keyboard looking stressed that tend to get pay
rises and eventually promotions into managerial positions. This is really just
down to the limitations of human psychology. If you look like you're working
hard you must be being more productive than someone who did the job without
fuss, then went out to get a sandwich.

~~~
DougBTX
I'd disagree with your description of "super-productive", that sounds like
normal-productive with time to fool around. Do something productive with the
extra time (either more coding or, better, something else business related
like running the finished app past someone who might have to use it) and there
might be a chance of hitting "super-productive". (fast + time wasted = normal
speed)

~~~
hvasishth
While I agree with fast + time wasted = normal speed, in reality it is not the
wasted time that plays the role. In most companies developers don't have a
fixed 8 hour job and most of them work more than 8 hours a day on a routine
basis. I have seen managers who valued the total time spent working more than
the actual work accomplished. So a developer who works about 8 hours a day was
ranked below someone who spent 10-12 hours a day working even though it was
the former who was accomplishing more tasks.

~~~
motters
It's often hard for a manager to judge how productive a developer is being.
Often they're insufficiently qualified to judge the standard of the code being
produced or whether one solution is more elegant/reusable than another, and
instead are just using heuristics which work for other types of employment,
such as estimating how much overall time and effort was put in.

------
RyanMcGreal
From the comments:

> I’d love to see some metrics on the average life expectancy of a line of
> code for different programmers. I know that some of my best code was written
> and has sat there with minimal changes ever since.

Now _that_ 's an interesting idea.

~~~
pyre
Not necessarily. There's plenty of horrible, horrible code that doesn't get
changed because it currently works, and it would be too much of a hassle to
try and de-tangle it. There's also really awesome code that gets replaced
because the requirements have changed and it needs to do something completely
different.

~~~
patio11
I throw out about 50% of all code written for A/B tests within, typically, a
week or two. If it weren't for all the business value added by it, I guess I
would suck as a programmer.

------
clueless123
It is because true productivity is _very_ hard to identify, specially when you
factor in quality, mainteinability, efficiency and timeliness. That is why
managers should be as qualified as the people they manage.

 _Programmers do some thinking & some typing, the more you do of one, the less
you do of the other. (don't remember the original author)

_The lazy engineer is the best engineer.. If not for lazy people we would
still be living in caves

~~~
Tamerlin
That's completely true.

Unfortunately, in the world of programming, most people get rewarded for
putting in extra hours rather than for being good at their jobs.

My pointy-haired manager rejected a design that I developed for our current
project because I think he didn't understand it... instead we went and cloned
the existing bug-ridden, convoluted, user-hostile app, following its example
at every opportunity, and leading to a HUGE increase in project scope...
exactly what I had predicted and attempted to avoid.

In the end what should have been a six-week project for a good 4-person team
turned into a 4-month crunch for a 10-person team saddled with several run-of-
the-mill and a few genuinely incompetent members... and the worst of the
incompetent ended up being the primary architect based on his ego and
politics.

------
meunierc
From the article:

> someone who stares quietly into space for a few minutes

...and exactly here lies the problem. I've been fired from a job because
according to an old retiree who never saw anyone programming before, "he spent
his days scratching his beard and looking blankly at the screen". No mention
about the job being done and the extra $1M my ideas saved. And certainly no
apologies after they had to replace me by a whole external company.

~~~
DougBTX
I guess the magic happens when you found that company :-)

------
tigerthink
I'm young enough that I can still change my career easily, and I often worry
that I'm not one of the super productive programmers, and that I'm wasting my
time and that I should choosing a different career.

Is uber-productivity significantly enhanced by choosing the right development
methodology (e.g. test-driven development) or is it mostly something innate?
Aside from stories like rdouble's (which I don't find _that_ helpful, since it
doesn't contain information on rdouble or his employer's domain expertise),
what is the evidence that super-productive programmers exist?

~~~
maddalab
I have found that uber-productivity is domain specific. I might be uber-
productive in a particular domain (Java programming), however put me in an
environment that does Groovy programming and I will stink as much as the next
newbie. However good programmers develop techniques for meta-uber-
productivity. They know what it takes to get uber-productive in another domain
in a short time and what works for them. My way to try and me more productive
in any environment is to get my hands dirty, start soon and make changes
often. Practice makes perfect. As an individual you can be uber productive,
just practice more of what you want to be productive at. Want to be productive
at running a business, start your own and practice it. Want to be uber
productive at programming, write code lots of it, and so on and so forth.

~~~
ahlatimer
I've found that most of the competent developers I've met haven't had a whole
lot more difficulty switching languages than the significantly better
developers. There's a lot of synergy between modern programming languages.

For instance, I started with Java, then moved to Python, learned COBOL and a
little bit of php and ASP around the same time, then finally switched to Ruby,
where I do most of my programming now. A lot of the things I learned in Java
were still relevant in Python, and the same was true with the switch from
Python to Ruby. COBOL was a bit of an outlier since I wasn't using the OO
version of COBOL, but I already had a grasp on logic and flow of control, so
even that wasn't that much of a stretch.

I'm definitely not one of those elite programmers, even though I do seem to
grasp concepts better than a lot of my classmates, so I find categorizing
domain as a programming language in relation to programmer ability is flawed.
Once you've achieved competency in a few languages, you should be able to
switch languages without too much trouble, assuming those languages at least
have a moderately similar paradigm (a notable exception might be, say, Java ->
Lisp).

It's the ability to understand _concepts_ that tend to separate the good from
the mediocre, and that might have been what you meant when you referenced
"domain."

------
boredguy8
The bare truth is that productivity isn't defined, so it's not measured, so
it's not rewarded algorithmically.

------
ericb
Honest questionn--did the productivity study where the oft-quoted 10x number
comes from count lines of code as the productivity measure? If so, lines of
code avoided would move a developer into the "less productive" bucket. Anyone
have a link to a source for this number?

~~~
smokinn
Dr. Greg Wilson (editor of the Beautiful Code book that spawned Beautiful
Architecture later) is working on a new book that talks about exactly this
kind of thing.

<http://pyre.third-bit.com/blog/archives/2910.html>

Basically, he says that professional understanding of software is still in the
lore stage where we gossip about what works and doesn't rather than empirical
studies based on evidence.

About this specific number though (the programmers are X times more
productive) that's often repeated:

 _To date, these studies have mostly been confined to academia. Most
professional developers are vaguely aware of some of the results, but often
get the details wrong. For example, hundreds of books, blog posts, and
presentations claim that the best programmers are forty times better than the
worst—or fifteen, or a hundred, or some other number. Almost none of the
people repeating that claim realize that it originally came from a very small
study (twelve people) run for a very short time (one afternoon) in an era of
batch processing and punch cards._

~~~
btilly
I don't realize his "fact" for the simple reason that he is wrong.

For example I often quote a 10x figure and cite _Peopleware_ as a source. They
draw their data from measurements taken of hundreds of different programmers
working at different companies in different languages in the mid 1980s. Which
is a lot more solid than the punchcard study he cites which I have honestly
never heard of.

------
umjames
I'm starting to get a little burned out about trying to maximize my
productivity. It's not a easy-to-understand, linear thing in most professions.
No one really knows how to accurately measure it, and once you come up with
something, you can game that system to produce false results if it benefits
you.

I think the best approach for anyone is to do the best you can with what you
have. It's more important to get something done than to worry about if the
amount you got done is greater than most others. You certainly should do
whatever you feel you need to do to optimize your "productivity", but don't
get distracted or depressed trying to be #1 in the world.

------
clofresh
I think management uses salary to keep people at the company rather than to
motivate them to be more productive. And if you're a manager, you want to keep
people who have a lot of knowledge of the code that isn't either well captured
in automated tests/documentation or easily figured out from looking at their
code, ie. crappy programmers. Good programmers are able to write simpler,
better tested and documented code so it's less work for others to maintain it
if they leave. Paradoxically, if you're working at a 9-5 programming job, you
have more incentive to be mediocre than great.

------
trapper
The last time I was employed I got frustrated with this having deployed 5
applications to customers in a few months on my own, and simply negotiated a
contracting role. We came up with a fixed price for each job, bugs included,
and I tried to make as much per hour as possible. My hourly rate ended up
being >250$/hr, and the application is still in production now 7 years after
deploying.

The other comments are correct; if you aren't willing to take any risk, then
you don't deserve the benefits. If you think you are good, put your money
where your mouth is :)

------
dusklight
I think 10x is really not the right number.

First off there are the net negative producing programmers, you can't say the
good programmers are 10x the productivity of those guys, because that would
make them 10x worse, which is incorrect.

Second off, I think the variation between programmers can be much bigger than
10x, easily 50x or more. Of course the 1x programmers really don't like this
idea, because their egos cannot handle the concept of someone else being that
much better than they are.

~~~
Psyonic
50x? Really? That means they achieve in a week what the 1x programmers achieve
in a year. I'd say its more likely they are infinitely more productive (as in
produce things the 1x programmers could never produce), but those kinds of
projects are rather uncommon.

------
ggruschow
Productivity based compensation for thought-workers isn't a panacea. Expenses
based on time, income habituation, success or blame attribution, and
differences of opinion on what is productive can actually make it a pretty
horrible experience -- even for people who are well above the average.

Time-based compensation and productivity-based firing can be a pretty good
system for a lot of people in a lot of situations.

I was hiring for some other jobs recently, and I was surprised at how the
group I was hiring from thought about their compensation. It wasn't "I deserve
$X", "Chris makes $Y", or even "I think I can get them to pay $Z." They'd come
to me and say "I need a job that pays $A/month because [$A ~= monthly expenses
+ a little extra niceties + a safety cushion in case something bad happens]".
It was refreshing.

~~~
Poiesis
I started responding to disagree with you, but now I'm not sure what you're
saying so I'll just chime in with my views. :)

I actually think production based pay is refreshing. I've personally worked
under this system (OK, so technically my wife did). It is really egalitarian.
Unfortunately it is also very uneven, as production capabilities vary
considerably and at times disappear complete (i.e, you're sick). Also, as you
pointed out for software development it's pretty hard to find decent metrics
that don't deteriorate when you optimize solely for them. In her field
(medical transcription), it was more clear-cut with a payment per line and
penalties for mistakes.

From the lazy, employee-based-safe perspective I can certainly agree that
time-based compensation is attractive, but my sense of self worth would prefer
being paid on performance. I'd certainly prefer to hire based on it.

Really the current system is probably roughly as good as you're going to get
right now. There are all manner of intangible pluses and minuses to a
particular person and a lot of places take this into account for compensation.
It makes the process less transparent but it at least allows flexibility.

Just one example--I like to think that I'm helping out less experienced
developers when I'm explaining some concept of business process or something.
But I'm certainly not adding code then. And what of managers? Good managers
are certainly valuable but their personal contribution is even less measurable
than that of a developer.

~~~
Psyonic
That's one big problem I see with performance based pay, even if an accurate
personal metric were available. Time spent helping/mentoring others would have
a negative impact on a senior programmers bottom line, even though a company
generally wants to encourage this.

~~~
ggruschow
You can't be accurate when you need to hit multiple different targets with one
shot. It's exceptionally difficult to get people to agree on what's valuable,
and how valuable it is.. and the problem gets worse with scale.

------
nick007
what kind of salaried professionals do get paid based on productivity?

~~~
DenisM
The only people who get paid according to their productivity are the ones that
own their own business, individually or collectively (in a partnership).
Everyone else is paid "market rate" which is the lowest rate someone else is
willing to accept to do the same job, and is able to deliver. These are
completely different compensation models.

~~~
Imprecate
Untrue, many salaried finance types eat what they kill in bonus comp, even
some developers (front office developers or quants) if they're responsible for
driving P&L and not just a cost center.

I guess you could argue that they aren't salaried since their bonus
compensation is usually significant, often many multiples of their relatively
low base salary.

~~~
DenisM
Good point. Having never seen one of those people I have forgot about their
existence when writing this post.

To the point consider this - if you are my employer and you pay me performance
bonus, do you have some money left for yourself? I imagine some of the value I
generate as an employee gets captured by the company, otherwise they wouldn't
keep me around, right? Therefore, self-employment is the only way to keep all
the value you have created.

~~~
Imprecate
If you own the business, why would any rational market participant buy your
product or service without expecting it to create more value for them than
they paid? Same thing, really.

The issue posed by the original post was that great programmers are not paid
proportionally to their output, not whether their employer makes a spread on
them.

You're correct though that the closer you get to the money the more value
you'll capture. You also take more risk. How many startups have folded where
junior engineers made $100k/yr and investors and founders left the endeavor
with nothing or a net loss? Depending on your life situation, being more risk-
averse and taking the guaranteed paycheck isn't such a bad thing.

------
stevedekorte
Seems to be a retelling of The Parable of the Two Programmers:

[http://www.csd.uwo.ca/~magi/personal/humour/Computer_Audienc...](http://www.csd.uwo.ca/~magi/personal/humour/Computer_Audience/The%20Parable%20of%20the%20Two%20Programmers.html)

------
pxlpshr
it's too bad we can't have a little roll reversal. most programmers wouldn't
last a month in the advertising industry, it's far more brutal and under-paid
than most development gigs unless you're founder/cto in an early-stage
startup...

------
kingkongreveng_
> The most productive programmers orders of magnitude more productive than
> average programmers

This is often repeated, never meaningfully demonstrated. I doubt it is true if
we are excluding unqualified programmers.

~~~
btilly
Never meaningfully demonstrated? Have you tried to verify the claim?

Go read _Peopleware_. You will find described very carefully set up coding
comparisons that routinely found a factor of 10 productivity difference
between different experienced programmers on the same task, and also a
discussion of what organizational factors lead to those productivity
differences.

There is other research on the topic as well. For instance
[http://www.computer.org/portal/web/buildyourcareer/fa035?utm...](http://www.computer.org/portal/web/buildyourcareer/fa035?utm_source=bronto&utm_medium=email&utm_term=Forgotten+Facts+About+Software+Engineering&utm_content=andrew%40badera.us&utm_campaign=BYC-
Issue+38-December+3) cites "individual differences" research that found a 30
fold difference between mediocre programmers and the top programmers. That
article is supposed to be a distillation of [http://www.amazon.com/Facts-
Fallacies-Software-Engineering-R...](http://www.amazon.com/Facts-Fallacies-
Software-Engineering-Robert/dp/0321117425) so I'd look there if you want
citations into how that research was done and what exactly they found.

~~~
kingkongreveng_
Well, I just googled the peopleware citation and it seems _the_ study backing
this often repeated claim is from the 1960s and people have plenty of
questions about its methodology.

I'll easily buy 2X or 3X productivity difference. I'm not buying these
casually tossed off claims about 10X or 30X productivity differences without
the supporting research discussed in detail front and center. Unacknowledged
differences of that magnitude would imply a massive arbitrage opportunity that
has persisted for many years. And that's just not realistic.

~~~
damienkatz
If you view computer programmers as mental ditch diggers, then the idea that
one could be so much more productive than another seems crazy. But when you
see it as a creative endeavor, it's completely rational that some could be
orders of magnitude more productive, even infinitely so.

For example, when you have a hard problem (like a networked 3d game with
physics) that is beyond the abilities of a developer A (he can't solve the
problems at hand, no matter how much time given), but not developer B (a
creative thinker who can solve the problems quickly), then I think you can
literally say Dev B is infinitely better than dev A for those hard problems.
Because it's going to take you infinitely many developers A's randomly poking
at their keyboard to solve the problems. But dev B will solve them in a reason
amount of time.

Now dev B isn't infinitely smarter, but for certain tasks, he's infinitely
more productive. The point is the productivity differences are highly context
dependent, and the greater the creative and cognitive load of the tasks, the
the greater the measurable productivity differences between the highest and
the average developers.

~~~
joe_the_user
But this reasoning applies if:

1) Knowledge is entirely linear. If there some tasks programmer A fails at and
some tasks programmer B fails at, then all you have is an apples-to-oranges
comparison (which is what a lot of the x10 chest-pounding comes down to).

2) Knowledge isn't shared in the group. My proudest moments have involved
actually teaching my co-workers _how_ to write a recursive descent parser, why
ACID matters in databases or how to divide a multi-threaded application
between worker and consumer threads. It might be true that if I'd just kept my
knowledge to my self and laughed as they failed, I might have been a 10x or
even a 100x programmer. But it was more pleasant and satisfying to be the guy
who actually helped everyone.

