
Why programmers are not paid in proportion to their productivity (2009) - ColinWright
http://www.johndcook.com/blog/2009/12/23/why-programmers-are-not-paid-in-proportion-to-their-productivity
======
mattmanser
I think John missed one.

The other thing I've seen happen is that the more productive programmers are
asked to do the more complicated things. So they'd be the ones creating a
javascript drag-drop widgets framework while the less capable were stitching
together CRUD apps with a bit of business logic in the backend.

This then looks like they're both delivering products, the CRUD app may even
earn a lot more money for the business in the short term too.

I've even seen this kind of skill discrepancy in call centres when I temped as
a student, this isn't restricted to the programming field. There's always a
couple of people who knew how to fix actual problems rather than just enter
payment details, they'd always be handed the troublesome clients but rarely
got paid more.

I ended up as one of these myself, but none of us ever complained about being
paid the same as Bob the lazy call avoider because it made our jobs far more
interesting and satisfying.

In the end I guess part of being a high performer is that you know you're
going to get the jobs that interest you and that in truth would just frustrate
and demoralize your colleagues. It's not always about the pay.

~~~
some1else
A good manager in a software company should have a decent grasp of project
complexity and output quality of his subordinates.

The examples listed seem to appear at companies that have in-house developers,
but don't really think of IT as an area they should focus on. Similarly, I
often found my ex ad-agency co-workers have trouble understanding why I have
to browse blogs/manuals, take time to think things through, sketch graphs and
sometimes just start over instead of refactoring.

Really, software managers should have no trouble noticing a 10:1 skill
difference between devs.

~~~
dmethvin
There are very few good managers, and when you think about it very few
programmers work in software companies. Instead they work for trading firms,
utilities, banks, government agencies, etc.

When the business of the company isn't software, there is a good chance that
the manager won't be a software developer. The criteria the developer is
judged by will have nothing to do with the complexity of the software or the
time it takes to create. Instead, their work will be judged and compensated by
the value it delivers to the organization. _Even if it's crappy software._

~~~
anamax
> The criteria the developer is judged by will have nothing to do with the
> complexity of the software or the time it takes to create. Instead, their
> work will be judged and compensated by the value it delivers to the
> organization.

You say that like it's different, or should be, at a software company.

I disagree. I think that all work for an organization should be judged and
compensated by the value said work delivers to said organization, regardless
of the organization type, regardless of the work type.

> Even if it's crappy software.

Surely you're not suggesting that crappy software is always wrong/bad.

Good software is often more expensive than crappy software. That added expense
doesn't necessarily produce more value.

Good programmers know that they're trying to maximize benefits-costs, not
maximize the former, not minimize the latter.

Worse can be better.

------
achompas
Why haven't I seen the following comment here?

    
    
        patio11  10 minutes ago  |  link
    
        Programmers are paid in proportion to the value they create. 
        If you want to make more money, work on stuff that makes money, 
        then ask for that raise.
    

Is there really any other explanation? Think about this like patio11 or
Greenspun: work on stuff that makes money/value for the business, go talk to
your managers, point to the thing you created and say "this generated $X in
revenue for us. I'd like to partake in some of that revenue."

Then head out to dinner or happy hour and enjoy your raise, or jump ship if
the company laughs at you.

Isn't this how the labor market for programmers works? If not, why aren't we
making this happen?

~~~
synnik
That isn't exactly how it works --

It is a valid argument for raises, especially early in your career. But at
some point, you are no longer selling your personal value to your boss - you
are competing with other programmers who are willing to give the same value
for a lower salary.

To get past that point, you need to have specialized business knowledge so
that outside programmers cannot compete with you.

The trick to getting very high salaries is to decrease the pool of competitors
for work, by increasing specialized knowledge above and beyond your coding
skills.

------
WeWin
Isn't the obvious, uncomfortable answer, that management wants to maximize
profitability? It's almost the definition of their job to find these 100x
productivity programmers and pay them the 1x salary. Also, note that when you
have an entire team of 100x programmers, and you are only paying them 2x or 3x
the salary of the 1x programmer, the manager has succeeded well in their goal
- not only has the pay-me-more-for-my-skill argument disappeared (they are all
the same 100x skill level) but you are extracting the massive amount of excess
productivity into profitability. bottom line is that if you really are a 100x
programmer, it is difficult to fully capitalize on that skill

~~~
freemarketteddy
>if you really are a 100x programmer, it is difficult to fully capitalize on
that skill

Only if you work at xyz corp!

------
Garbage
The best part of the article:

 _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.”_

~~~
Jach
Seems in line with Rich Hickey's "Hammock Driven Development" (Here if you
haven't seen his talk: <http://blip.tv/clojure/hammock-driven-
development-4475586> )

------
araneae
I disagree with all the reasons he listed... because this is true of all
careers, not just programming. I think it has more to do with our ideas about
pay more than anything else.

Quite simply put, in almost all professions you're paid for being there for
9-5. If you show up and do your work poorly or not at all, you might get
fired. If you do well, you will get a small raise. So to a small extent
productivity is correlated. But the salaries aren't proportional to
productivity; the biggest predictor of salary is if you're fulltime. You're
getting paid for your time, not what you're producing.

------
brador
Programming at the level of HN readers isn't a science, it's a creative art.
You buy artwork based on it's value to you as a finished product. Very few
people commission art from artists other than those who are very well known.

Conclusion - sell finished works of art, not your time. Effectively, SHIP A
PRODUCT PEOPLE WANT.

~~~
roel_v
"Programming at the level of HN readers isn't a science, it's a creative art."

Can we please stop circle jerking like this? I have no reason to believe that
there aren't a bunch of idiots on here, just as most anywhere else.

~~~
Cushman
Can we please stop using the phrase "circle jerk" to demean people we disagree
with? Just because there may be "a bunch of idiots on here" doesn't make it
Reddit.

~~~
roel_v
I don't 'disagree' with him, one 'disagrees' with opinions, and I don't waste
my time on that - opinions are like assholes, everyone's got one and most of
them stink. There was a factual claim being made, that somehow people who read
some specific pages on the internet (the HN pages) are smarter than others, a
claim arising from snobbery and self-aggrandizement; one of a false duality,
too, like your 'doesn't make it Reddit'.

~~~
Cushman
Whatever. Just get your damn ad hominems out of here.

~~~
roel_v
Did you even read what I said? It's _not an ad hominem_.

~~~
Cushman
Yes, it is. "Circle jerk" is a term used to denigrate someone who gives (in
_your_ view) unnecessarily effusive praise by comparing it to an adolescent
sexual behavior. If you feel the praise is unwarranted, you're welcome to
express that feeling -- and if you have evidence to support this, you're
welcome to present it -- without the insult.

~~~
roel_v
It's not an 'in my view', it's objectively wrong to outright assume that
somehow people who read some site are better than others. There is no
reasonable way to interpret the original comment in any other way.

Furthermore, it's not an ad hominem because an ad hominem is an argument that
is being made by discrediting that argument not on its merits but on an
unrelated other characteristic of whoever made it. I'm not doing that in any
way - the use of 'circle jerk' in this context is perfectly warranted as a way
to express disapproval of the poster's myopic thinking methods (or rather,
myopic world view based on lack of thinking).

------
agoder
I think there's a simple explanation for this: asymmetry of information. While
the programmer knows that they are a 10x programmer, the company hiring them
does not. Interviews, resumes, and referrals only provide a limited set of
information, and surely not enough to boost the company's perception of you up
to the 10x range. So that's why salaries are much more compressed than skill.

The standard economic solution for these types of markets is to offer a
"warranty", the idea being that the better product will be able to outcompete
on "warranty". For programmers that might mean agreeing to a contract where
you get paid, say, $300k, but if after X time you aren't performing well
enough then you have to pay back most of it. Actually this is sort of what
happens already with equity.

------
mvzink
If you have two programmers, and one is "10x more productive" than the other
in that he knows when to reuse or adapt other code, but there is a problem
that actually does require writing code, which one will put out a more
correct, reliable solution faster? I would guess that it would be the 10x more
productive programmer, because he/she doesn't just know when to reuse or adapt
other code, but also when to reuse or adapt algorithms, architectures, etc. or
"solutions" generally.

I'm annoyed that Cook is _still_ undervaluing these programmers in this
article by not explicitly mentioning solutions in general, but only "reusing
code", which is just a special case of reusing solutions.

~~~
esrauch
The '10x more productive' in this article was referring to people who reuse
and adapt, you seem to have it backwards. You are infinitely more productive
if you realize the problem is already solved. Not only is it faster, but it
also isn't as likely to suffer from bugs.

But I also think you are assigning to him a slightly different opinion than I
understood it. It's not just 'This would be a good time to use Excel!" or
"This would be a good time to use Library X!", it's "This codebase already has
something that is slightly different; we can probably generalize that slightly
and save a lot of headaches". He _is_ talking about people who write code
every day, but people who are better able to apply existing frameworks to the
new problem instead of banging out something from scratch.

Also with regards to your "still", this article is not new.

~~~
mvzink
No, I don't have it backwards and that is indeed the kind of programmer he was
talking about. I am only saying that the _"This codebase already has something
that is slightly different; we can probably generalize that slightly and save
a lot of headaches"_ situation is just a _special case_ of better, more
adaptive problem solving that doesn't necessarily rely on the "codebase
already [having] something that is slightly different".

And I know the article is not new, the point of "still" is that the article
seeks to address the undervaluation of these programmers, yet doesn't give
them their full due. This is because most (if not all) of the same programmers
who practice that special case of efficient problem solving _also_ are capable
of more generalized forms of efficient problem solving, and Cook doesn't
mention this.

~~~
esrauch
> are capable of more generalized forms of efficient problem solving

I still don't understand what you are trying to say. The entire point of the
article is that "people who are capable of the more generalized form of
efficient problem solving are more valuable". He's not saying that you never
have to sit down and get your hands dirty and write something from scratch, or
that the most efficient people never do that.

You are agreeing with what he wrote and acting like he said the opposite.

------
discreteevent
A corollary of this article is that experience is also undervalued. It is
experience and the ability to reflect on it intelligently that prevents people
from making a mess. Its that mess that is killing productivity in most shops.

~~~
eftpotrm
Maybe, but if you paid the juniors appropriately on that scale they'd never
get into the industry and if you paid the seniors on that scale the business
couldn't afford them.

------
daxxad
I think we should address 2 questions first before we can answer this. Why do
some programmers think they are 10x or 100x more productive than others? Is it
a myth or is it for real? Give some concrete examples of 10x productivity for
a start.

~~~
wes-exp
The 10:1 productivity gap is well established in the academic literature for
software engineering.

There are not many concrete quantitative statements one can make about the
profession, but this is one of them.

~~~
brider
Do you have any references for this, my good man? I don't mean to question
your comment; I want to learn more about how this has been established and the
nature of it.

~~~
azov
I don't have any references to academic research, but my own experience
interviewing people supports the claim. When presented with a simple coding
problem, some people just breeze through it, others take most of the interview
to finish it, and some candidates just can't solve it at all.

To the extent to which coding on a whiteboard is an indicator of real-world
productivity, there definitely seems to be at least 5x difference.

------
Zak
This article and general theme are based on an invalid premise. Many of the
most productive programmers are, in fact paid in proportion to their
productivity.

Such people are likely to found startups or join at an early stage or they're
likely to work at places like Google that issue large stock grants to many of
their most productive programmers. Those who don't are more interested in
stability than money.

Large non-software companies and governments fail to compensate their most
productive programmers proportionally because they have difficulty identifying
the benefits they're getting or simply don't value them all that highly. Most
of us consider it obvious that such organizations aren't the most desirable
work environment for programmers.

------
joelthelion
Because no one has found a good way to improve the quality of information in
the job market for programmers (yet).

It's still very hard for an employer to detect skill, and for a job seeker to
select good potential employers.

Could be an idea for a very useful startup :)

------
growingconcern
If he can't say that it's easy to measure whether someone is 10x more
productive than the average programmer then how can he say they are 10x more
effective? Also I work at 200 person game company and there is no programmer
that even performs close to that level. Maybe 2 to 3x the average for
absolutely exceptional programmers. But your average would have to be pretty
fucking crappy to get anything more than that (and even very talented
programmers aren't more than 2x the average).

~~~
onemoreact
Productivity in the shortest time scales is hard to measure.

But, when someone spends a few days and makes an optimization that literally
prevents well over 1 million dollars of new hardware from being purchased
that's real value. (This actually happened.) Create that type of value a few
times in 5 years and yes someone can really create 10x the value of the
average programmer.

PS: Not a programming example but
<http://en.wikipedia.org/wiki/Polymerase_chain_reaction> is one of the more
extreme examples. Kary Mullis literally created billions of dollars of value
paying him 10x what the average researcher makes for 40 years and it's still a
net win.

------
phzbOx
Why programmers are not paid in proportion to their productivity? Because they
procrastinate the other 50% of the time! (Obviously, it is a joke. But
ironically, we're discussing that on HN...)

~~~
wayathrow
Or they procrastinate and take it easy because there is an upper limit to
compensation per unit of time & effort. If I am truly 10x more productive,
that means I should be able to keep a steady paycheck rolling in with 4 hours
a week!

------
ericHosick
The most productive programmers are the ones who can solve the problem without
writing any code at all.

------
shawndumas
<http://www.readability.com/articles/uuek7ysi>

------
elspoono
Dead on.

What makes a good programmer good isn't the code they write, it's the code
they don't.

------
rasur
The article is from 2009.

~~~
ricefield
But, still a good article.

------
porfirio
I noticed something similar, though not as a programmer.

I tested videogames one summer, where it was my job to locate and report bugs.
It was soon apparent that there was huge variation in productivity: some
people submitted more and better bugs, in better written reports, than others.

Most people were hired as independent contractors through an outside company.
A select few would be hired by the actual game company, and kept on through
the season. Was it the most productive who were kept on? No. It was the people
who put in the most overtime hours, and made themselves available when the
company asked.

Call me an ignorant youth, but it seemed like, if they wanted to, they could
raise salaries, fire the bottom X%, and hire some more talented QA testers,
and still come out ahead.

Cook's explanation doesn't really explain this scenario, but I have a feeling
the answer is similar, for both the QA tester and the programmer.

My theory: management simply doesn't care, and doesn't need to. If you were to
walk out, they could easily get someone else at the exact same pay-grade. It's
only when your value to the company is crystal clear, and you are clearly
better than the competition, and that there's a viable threat that you will
leave somewhere else and actually get better pay, that a company will pay you
accordingly.

After all, economics doesn't say you get paid what you're worth. It says you
get paid the market clearing wage. You might be creating $200 of value per
hour for your employer, but if there are tons of people ready to work for $10
an hour and are just as productive, then you will get paid $10 an hour.

This is more conjecture, but I think for things to change, for people to be
paid according to their productivity, two critical pieces of information are
essential:

1\. Exactly how productive you are, relative to your peers. 2\. Exactly how
much people of varying abilities make.

The problem is, for #1, the metrics are bad if at all existent. For #2,
there's a huge taboo against telling people what you make, which ultimately
helps employers keep wages lower.

I think my QA testing situation would have been different if say, the men in
charge took some pride in it, and only hired great testers. They didn't, they
were just filling slots, so the QA on the QA testers themselves was pretty
shoddy.

~~~
greenyoda
"Call me an ignorant youth, but it seemed like, if they wanted to, they could
raise salaries, fire the bottom X%, and hire some more talented QA testers,
and still come out ahead."

Not ignorant at all; this is a very insightful observation. I've seen the same
thing from the programming side. Unfortunately, an unskilled programmer can
create more and longer-lasting damage than an unskilled QA tester -- some code
sticks around for decades and has layers and layers of new code built on top
of it. Thus, bad programmers can drag down other programmers' productivity
long after they've left the project. So the advantage of replacing a lot of
bad programmers with a handful of good ones who are better paid could be even
greater.

Not to mention that a smaller group has much less communication overhead than
a larger group (as described in The Mythical Man Month).

