
Why programmers are not paid in proportion to their productivity - shawndumas
http://www.johndcook.com/blog/2009/12/23/why-programmers-are-not-paid-in-proportion-to-their-productivity/#
======
edw519
The subject of this post may be the number one reason for a good programmer to
stop being an employee and to start being an independent business person.

2 of my own examples (I have many more, as many of you do too):

As a one man IT department, in 15 months I reduced my annual budget from $2.3
million to $600K, cleared up 500 old tickets, and implemented 4 mission
critical applications. My reward? A 4% salary increase. (I gave my notice
during that review.)

As a contractor, I maintained all the software for a $100 million company that
was shopping for an ERP package. They were stunned by the 6 & 7 figure price
tags and 2 year project timelines. I proposed a project that would add
everything they needed from these ERP packages to their current system in 90
days. I hit the target and got paid $225K.

If you're a programmer who is 10x to 100x more productive than your peers, the
last place you should be is as an employee without equity. Get out there and
find someone who needs what you can do. You'll both be much happier.

~~~
dcposch
"As a one man IT department, in 15 months I reduced my annual budget from $2.3
million to $600K, cleared up 500 old tickets, and implemented 4 mission
critical applications. My reward? A 4% salary increase. (I gave my notice
during that review.)"

Wow, that's pretty horrifying. I certainly agree with your point. But...

"As a contractor [...] I proposed a project that would add everything they
needed from these ERP packages to their current system in 90 days. I hit the
target and got paid $225K."

The big ERP vendor may well be grotesquely inefficient, or their software may
provide a lot more than your client needed, or both. Congrats for saving your
client so much money. But complaining that you "only" made $225k for a 90-day
project, working by yourself, seems a little hubristic.

~~~
rfrey
I don't think he was complaining - I think he was favorably comparing his work
as a contractor to his experience as a salaried employee.

------
Murkin
The real reason programmers are not paid in proportion to their productivity:

    
    
      They don't demand it.
    

I had the privilege of working with some extremely talented and productive
people. Sadly, many of them were making market salary (or less). Contrary to
popular belief, many companies are quite capable of noticing and trying to
keep productive people. But rarely by throwing money at them.

Related anecdote: I have meet a few startups lately that started the
conversation with:

 _"We are looking for extremely talented and productive people"._

And finished with:

 _"Compensation ? Well, we checked online, the average pay for your experience
is.."_

~~~
waterlesscloud
It's amazing how common that is.

"We want top people."

"We want to pay average."

~~~
rch
If they can't pay more, try asking for a 4 day work week.

For smaller companies/startups I also prefer to receive fresh hardware
(macbook,mini,etc.) at signing.

~~~
illumin8
Fresh hardware? Are you kidding? If you make a decent salary you can buy your
own hardware whenever you feel like it. A $2K MacBook Pro is a drop in the
bucket compared to paying a 6 digit salary.

~~~
orc
If they pay you and let you buy the MacBook, it's after tax.

~~~
usaar333
$3k is still a drop in the bucket

~~~
rch
Great! e-mail me for my address..

------
raganwald
I'll ask again: What is the objective and repeatable metric of programmer
productivity? One of the reasons I avoid writing about productivity is that I
have no idea how to quantify it.

But if someone can show me how to measure it, I'm confident I can show him how
to get paid by it.

~~~
palish
The only objective and repeatable metric of programmer productivity is if a
single programmer is assigned the task of delivering a tool or component, from
scratch, by himself. His productivity is the inverse of the time to delivery.

And that doesn't take into account maintenance.

~~~
raganwald
_that doesn't take into account maintenance_

This excellent insight takes us to a place where productivity is even harder
to measure: How does one measure the _value_ of a piece of software? Software
that has subtle bugs flying under the rader of our test suite has some kind of
negative value. Software that lowers the "productivity" (however we measure
it) of future programmers who need to extend or change it has negative value
associated with it. How do we measure that?

Imagine the exact same formally specified requirements handed to four
different programmers:

The first programmer, "Ned," does the job in a straightforward fashion, and
delivers working code passing all tests.

"Fred" does the job using uncommon techniques (parser combinators, for
example) in less time and produces less code.

"Ed" proposes that if some of the requirements are relaxed, there is an open
source solution that can do the job with trivial integration.

The last programmer, "Jed," sees some commonality with some existing code and
proposes that the scope be expanded to produce a new piece of infrastructure
(message queues, web services, SOAP, &c) solving a more general problem.

How do we judge Ned, Ed, Fred, and Jed?

~~~
palish
By how fun they are.

As people.

I'm convinced the only real-world metric that matters is "how much other
people want to work with you". Being an easygoing, fun person facilitates that
dramatically.

~~~
danenania
I think this is true up to a certain point, then stops mattering. Once someone
is at the 'pleasant enough to be around' level, I'd much prefer he/she be more
intelligent or skilled than more fun if we're working together. This is partly
because lower key, quieter, more intelligent people can often turn out to be
more interesting and fun in the long run than people who have great social
skills and confidence but less depth in their thinking and personalities.

~~~
saturdayplace
If we extend "fun to work with" to include "quieter, more intelligent" people,
I think palish's definition may work rather well. That group definitely falls
into "people I want to work with."

~~~
jimbokun
Weirdly enough, I just finished reading about how NBA players overwhelmingly
wanted to play with Bill Russell over Wilt Chamberlain, as part of an argument
that Russell was the better player.

------
mikepk
I understand this post is specifically about salary and money, but in my
experience there is a kind of "gray" market of compensation that truly great
hackers participate in.

This usually (but not always) means that the person has a lot of latitude to
work on what they want to, they can work with the technologies they want to
work with, can work the hours they want to work, have the luxury to not always
have to report on progress or have a lot of management oversight.

The degree with which someone like this can participate in these "happiness
perks" usually is commensurate with how good they are. There is a great TED
talk on intrinsic vs extrinsic rewards in terms of motivation. I think the
market "works" in the sense that great hackers aren't actually as interested
in making gobs of money (they don't want to get screwed either) but are
usually more interested in these other more intangible kinds of incentives
(like freedom, autonomy and mastery).

The most talented engineer / programmer I've ever known was only paid at the
top end of the "average" pay scale in the research lab I worked at. On the
other hand, he was left pretty much alone to work on whatever he wanted to
work on. He created amazing things and was genuinely happy, even though in
pure monetary compensation, he was radically underpaid.

------
latch
The 10x thing is an understatement..but say 10x is accurate.

Take an average programmer, and try to convince him that he could be two times
more productive..a junior programmer might buy it, but any average programmer
with "experience" isn't going to believe it. Forget about telling him that he
could be 4 times of 5 times more productive.

Now move up to the manager and tell him that his team could be 2x more
productive. No way will your average manager believe it if for no other reason
than it makes them seem pretty incompetent.

I've tried the experiment before. An example...A small team was complaining
about their workload and kept saying they needed to double the team size.
Management agreed and was trying to get budget. This dragged on for a while
(along with the complaining). I asked why, instead of doubling the team size,
they simply didn't double the productivity. The concept of even thinking about
being more productive was completely foreign to them. They wouldn't talk about
what might improve productivity - there was no point because clearly the hard
working team couldn't work any harder...working smarter? Nonsense..they were
experienced developers.

The point? Everyone thinks they are better than average. Admitting that you
could be 2x (forget about 5x) more productive is like admitting (in people's
minds) that they are slacking off. This works at the individual, management
and company level.

More productive programmers aren't paid more because, while everyone knows
some programmers are 10x more productive, every employee thinks he/she has
little room to grow, and every manager believes his team is awesome.

~~~
alanfalcon
Did you propose a 2x salary increase to accompany the 2x productivity
increase? It could get the programmers, if not the managers, to decide your
way was worth a try.

~~~
gnaritas
Why should anyone require a salary increase for somehow to show them how to do
their job in an easier way? Unproductive programmers are unproductive because
they do too many things manually and don't automate repetitive parts of their
jobs.

I know programmers who still, after years and being told to use rsync and
automate the pushing of their code to production, still manually open up an
ftp client and one by one upload just the files they know they changed. Dudes
could save probably a few hours a week easily _and_ do less work but the fear
of... learning something prevents them from doing it.

~~~
rwmj
They fact that the choice is 'rsync' _or_ 'ftp' scares the heck out of me.
Doesn't everyone use a packaging system with reproducible builds, deploying
these packages to staging first, testing it, then deploying the same _signed_
package live using real configuration management (eg. Puppet) ...?

~~~
count
The _vast_ majority of companies don't do this. It's scary, but it's life.

~~~
gnaritas
It's not scary at all, having that kind of process for a small shop would be
absurd. When your developers are the only tech guys you have, and do all
system administration, database administration, new programming, bug fixes,
and deployment, you don't need or want red tape between yourself and yourself.

That kind of process works for large teams where different people are doing
those jobs and need to collaborate effectively without finger pointing; but
it's not for a small cowboy team at all. You simply can't maintain that kind
of formality and process when you're doing everything.

------
RyanMcGreal
Poignant conclusion:

> 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."

------
lyudmil
It's important to note that no one is paid in proportion to their
productivity. In a free market, you're paid in proportion to your bargaining
power. This means both that for programmer compensation to be fair we need to
get better at translating productivity into bargaining power, and that there
are some limits even if we got the first part exactly right (regardless of
productivity, programmers will not be paid as much as CEOs, unless they are a
CEO).

------
swombat
Actually, programmers can be paid proportionally to their productivity... they
just need to run their own businesses (which has the downside of requiring the
programmer to learn to be an entrepreneur... but it can be very financially
rewarding). <http://swombat.com/2011/4/26/productive-programmers>

~~~
mikepk
I find my skill as a programmer has substantially diminished the more I've had
to spend energy and focus being an entrepreneur. I believe there's a myth that
the hacker can do it all and do it all well. In reality I think you end up
being stretched like... butter scraped over too much bread. :)

It may be a cop-out but now I'm looking for "top people" to hire, but what I
usually mean is someone who can have the programming focus I don't have
anymore. I'm looking for "me 6 years ago" the hacker who loves products and
wants to build a business who's at the beginning of the entrepreneur track.
Damn damn hard to find.

~~~
Travis
Second the idea that my programming output has declined in terms of quality as
I focus more on business related aspects. It forces you to look at everything
in context -- better code quality gets you more maintainability, but at what
cost? Every decision I now make has a trade-off; as a programmer, I can afford
to throw more time to elegantly solve a problem. As an entrepreneur, I just
need it to work as well as I've defined, for a specific cost.

Great Baggins reference as well.

------
michael_dorfman
If programmers _were_ paid in proportion to their productivity, there are
quite a few who would owe me money.

Of course, if you turn back the clock far enough, there may be one or two
folks out there who would say the same about me.

------
alecco
Let's accept this and move on: programming is seen as a lowly profession by
most business and hr people. And it isn't going to change in the foreseeable
future. But you know what? They need us more than we need them, right now. PG,
Spolsky, and many others agree it's preposterous to try to change society. The
way out is either start your own business or join a small team with similarly
talented people.

Don't waste your life in a rat race.

------
sampsonjs
Uh, because the '10 times more productive programmer' is folklore, at best? It
may be true, but there's not much hard empiricism behind the claim. See
[https://www.readability.com/articles/5egv0hme?legacy_bookmar...](https://www.readability.com/articles/5egv0hme?legacy_bookmarklet=1).
Cook admits it's hard to tell who's more 'productive'. Well, if it's hard to
tell, why take that claim for granted in the first place? I am sure Cook and
everyone else likes to think they're the 10x programmer, however.

~~~
chalst
Right. That link deserves to be more widely read.

The 1968 Sackman, Erikson & Grant paper is available as a scanned PDF, btw:

[http://www.dtic.mil/cgi-
bin/GetTRDoc?AD=AD0645438&Locati...](http://www.dtic.mil/cgi-
bin/GetTRDoc?AD=AD0645438&Location=U2&doc=GetTRDoc.pdf)

------
stcredzero
There was once a famous Smalltalker, a renowned toolmaker who took a "for now"
job at a telecom. He could do all of his week's assignments in a single day or
two, where his coworkers would take the whole week to accomplish less. So what
did his boss do? Basically, demand that he suffer as much as his coworkers.
Result: The boss lost his most productive and talented worker.

~~~
rick888
That's why you get it done and don't tell anyone else about it until the due
date. People that get things done quickly are usually rewarded with more work
and responsibility at the same pay.

------
chrismealy
This is not just in the programming business. Highly productive employees are
generally underpaid relative to their peers. In his book, "Choosing the Right
Pond", the economist Robert H. Frank attributes this to status-seeking. Short
version: the highly paid employee could make more elsewhere, but then they
wouldn't be the the big fish in the small pond anymore. On the flip side, the
relatively low-productivity employee may be overpaid in compensation for the
shame of being the worst programmer on the team.

------
mikepk
For the people that are saying that the "10x more productive" programmer is a
myth, I assure you these people exist, but you're likely not one of them (nor
am I).

The most impressive hacker I've ever known worked with me in the advanced
research lab in a ginormous tech behemoth company. Let's call him "Bob". He
was so good that people in the team would sometimes call him "Super Bob".

There are lots of stories I could tell about him, but he (working alone) was
often able to hack out stable, working code in months, solving problems that
had proven too difficult for entire software engineering organizations and
multi-year projects. This happened more than once.

"Super Bob" got paid at the top end of the "average" pay scale, but was
genuinely happy. He could work when he wanted, and on what he wanted, had his
own lab, and no one messed with him. I tried to recruit him into my first
startup when I left the company but I came to realize he wasn't interested in
making tons of money, especially if it meant taking risk, sacrificing the
access to huge resources (and toys), freedom and autonomy that he'd developed.

------
johnwatson11218
I just read "Linked" by Albert-Laszlo Barbasi and he talked about different
kinds of networks. One example is the number of inbound/outbound links you
find on a highway map versus a map showing links between airports. The highway
map gives rise to a normal statistical distribution with only a few towns
having so many or so few roads in/out that they fall far from the mean.

The airport map is a different story. There are many airports with just a few
connecting flights and there are just a few airports with a large number of
connections. When you make a plot that shows number of connections on the
x-axis and the number of airports having that many connections on the y-axis
it shows a power law. The graph is very high near the y-axis and drops off as
you move to the right. Finally you get to the large airports like LAX,
Chicago, and New York.

I bring this up here because I think the issue of programmer pay and
productivity has similar properties. The salaries are distributed normally
with a mean and the vast majority earning within 2 standard deviations. If you
could measure productivity of each programmer and make a graph that showed the
productivity level on the x-axis and the number of programmers working at that
level on the y-axis then I don't think the graph would look like a normal
distribution. Rather I think it would follow the power law just like the graph
of airport hubs.

I know this is somewhat speculative on my part but I think it could also be
that the top programmers are so productive because they are highly connected
in terms of programming concepts and techniques. The article mentions their
ability to come up with alternative solutions. I think they get like that by
working on different projects over time. This is also how the power law
networks (also called 'scale free' networks) are thought to form in other
areas according to the book.

~~~
jshen
I'm pretty sure programmer productivity is a normal distribution

~~~
johnwatson11218
If that is true then I don't think you would expect to see people who are 10X
more productive than the average. The tails of the normal distribution fall
off very quickly. I think most people who have worked in the industry can
think of at least one programmer that they have worked with who was 10X more
productive than the average.

~~~
jshen
The rightmost side of the normal distribution can be 10x the mean.

~~~
johnwatson11218
yes there are points under the curve out at 10X the mean but they are very,
very rare. The normal distribution falls off a cliff. I don't have the
reference in front of me but something like 99.6% of the population will fall
within 2 standard deviations of the mean. This same issue comes up when people
try and predict something like the daily fluctuation of the Dow Jones
Industrial average using a normal curve. They think that there are random
swings up and down but that large swings of 500 points are more are very
unlikely. Then those large swings come along and show everybody that it isn't
smart to use the normal distribution to try and model the absolute change in
the closing price.

The main point here is that programmers who are 10X more productive than the
average coder seem to be not so rare. Many people have stories about having
worked with guys like this. Therefore I don't think you should use the normal
distribution to model the distribution of productivity in programmers. I think
there are many guys at the low end of the scale and it drops off slowly as you
move into the higher productivity. And NO you can't include the negative
x-axis to get a symmetric, "normal-like" distribution. In this model the
negative values on the x-axis don't mean anything.

~~~
rprospero
I would have to disagree on two counts. The first point is pedantic, but, in
the standard normal distribution, half the curve is over ten times greater
than the mean. Of course, that's cheating, since the mean is zero, but it's
not impossible for the relationship between the mean programmer productivity
and the standard deviation to allow for large number of programmers with 10x
the mean productivity.

The catch is that any normal distribution which allows for large numbers of
10x programmers requires large numbers of programmers with negative
productivity. However, I disagree that those values are meaningless. Rather,
it simply indicates a programmer who makes code worse. I would readily argue
that, for every 10x programmer, there's at least two who create more bugs than
they solve.

------
ja27
I've been frustrated over the years to see programmers rewarded for putting in
extraordinary amounts of effort - often due to crises of their own making. The
guy that designs and builds a service that's delivered on-time and works
without major issues gets ignored but we'll heap praise (and money) on the guy
that has to work 80 hour weeks for 2 months after the due date or the guy that
works all weekend to fix a bug that he caused in the first place.

~~~
JoeAltmaier
Yes! I've seen the worst team in the company get praised, wined and dined
because they pulled the customers bacon out of the fire - the fire they
created by bad programming.

------
6ren
oblig. negative LoC story
[http://www.folklore.org/StoryView.py?project=Macintosh&s...](http://www.folklore.org/StoryView.py?project=Macintosh&story=Negative_2000_Lines_Of_Code.txt)

> I think the weakest way to solve a problem is just to solve it; that's what
> they teach in elementary school. In some math and science courses they often
> teach you it's better to change the problem. I think it's much better to
> change the context in which the problem is being stated.
> <http://www.ecotopia.com/webpress/futures.htm>

I've often changed a problem so the difficulty disappears; but it's usually
after I've worked on the problem a bit. I must admit it is kinda disappointing
when I have to sack all my clever and complicated ideas, that I've become
attached to.

------
Stormbringer
I think the brick-laying analogy is a lot more on target than John realises.

A lot of the below average programmers go out and start slapping down bricks
at a great rate of knots. Planning? "Ha! You ain't gonna need it" they say.
Design? "Pffftt, is this the bad old days of the PDP-11?" they scoff. "I do
automated unit testing, why would I fire up the site in an actual browser?
That's so 90s!"

The problem is that a lot of the time the bricks they are laying get torn down
and rebuilt, and torn down and rebuilt, over and over and over. This gives the
appearance of productivity, but gets you nowhere in the long run. Even if you
could run at 50mph for hours on end you wouldn't win a marathon by running in
the same small circle over and over again.

Examples of ways the bricks can go wrong:

Not building the right thing (they asked for a gazebo, you built a garage)

Not accounting for edge cases (the walls should meet)

Not doing proper testing, or leaving the testing until very late in the
process

Not making the design flexible enough to account for likely changes during the
project (no real world equivalent springs to mind)

Not building solidly enough (doesn't provide load bearing support in the right
places) (closely related to the "catching exceptions is for wussies" school of
thought)

Leaving odd holes and gaps in the brick wall (security issues)

etc. (Feel free to add your own, fun for the whole family! :D )

------
saturdayplace
> most productive programmers are orders of magnitude more productive than
> average programmers.

This seems to be so generally accepted that it's stated in the article as
fact, without anything to back it up. As raganwald mentioned, we really have
no metric for productivity. So, while your gut may tell you that you (or
someone you know) is multiples more productive that you are, all you really
have is your gut.

------
scotty79
Salary has nothing to do with work. Getting and keeping high salary is all
about luck and cunning. Your work does not have to be extremely useful or
valuable.

I don't know where this idea that world is fair comes from.

------
cygwin98
Here are my random thoughts about the reasons (not in a specific order):

1\. they are not part of a software company, say, not generating revenue
directly, so they are not high on the payroll list

2\. the pay is based on the overall performance of the whole development team,
so the great programmers' productivity got mitigated by the worse ones'

3\. high productivity may mean technologically superior products, however,
superior products don't necessarily lead to market success

4\. if there is a function: profit = f (productivity), it may be more likely a
logarithmic one, rather than linear, e.g., there is a diminishing return on
productivity

5\. even if it's linear, the owners won't pay accordingly, because of the law
of supply and demand

5a. own yourself when you have a chance, if you think you're great hackers

------
gabeh
Steve McConnell revisited this subject recently:
[http://forums.construx.com/blogs/stevemcc/archive/2011/01/22...](http://forums.construx.com/blogs/stevemcc/archive/2011/01/22/10x-productivity-
myths-where-s-the-10x-difference-in-compensation.aspx)

I think about myth #1 when this subject comes up - "Part of the issue is that
I’m underpaid a little; a bigger part of the issue is the other guy is
overpaid a lot."

Edit: Just saw there was a discussion on this article about 90 days ago:
<http://news.ycombinator.com/item?id=2131550>

------
martiell
A lot of the discussion seems to assume that a given developer has a constant
level of productivity and hence, can be salaried according to that level.

I'd say a developer's productivity can vary according to motivation; who
they're working with; how interesting the work is; whether they're well
managed or not...

So, while salary is a linear measure, it makes no sense to me to assume that
productivity can be measured the same way.

I'm fairly sure my own productivity can vary by as much as an order of
magnitude according to circumstances. Wonder what I should be getting paid? :)

------
davisp
I see quite a few comments addressing the fact that there's no way to directly
measure 'productivity' of a programmer. And there's also the questioning of
whether the 10x figure is made up or not (Its not. There's research that
attempts to measure productivity, but its always by some proxy measure,
usually time to complete a task. There was a post not too long ago that
collected various articles on the origin on the 10x number).

So far I haven't seen anyone point out that there are lots of abstract
concepts that we measure and rank without having a specific measurable
quantity. Art is the first thing that comes to mind. What makes someone a
'good' artist? Even in things people might normally consider numbers based
like college football rankings aren't purely objective.

The to deciding some ranking and relative comparisons is to ask people
familiar with the subject to compare to instances of the set. In this
particular case I could see having the team rank each other member or assign
some numeric score representing their opinion. Giving this and some brief
written reasoning for the scoring it seems like management would be able to
get a clear picture of who the most 'productive' programmers are. There'd be
obvious chances for pitfalls and politics in such a system, but if it were
applied with some sanity it seems like it could work.

------
pge
To complain that programmers are not paid in proportion to their productivity
is to imply that other professions _are_ paid in proportion to their
productivity. That is very rarely the case. Sales, perhaps, is the only area
where there is a clearly defined performance metric that drives compensation.
In any other role, there are people making roughly the same salary with
substantially different levels of performance.

~~~
j_baker
Sales is hardly perfect in this respect. It's _harder_ to game sales stats,
but I have yet to see a sales ranking/commission system that wasn't gameable
somehow.

------
kamaal
For the most part I think what the user edw519 tells is perfectly correct. If
you sure of your competency and confident that you can actually be 10x or 100x
more productive than other than you must work for somebody who pays you 'per
unit of work done' rather than somebody who pays you lump sum.

Unfortunately unless you make people pay for services they don't recognize
your worth. Back here in India, like every where else good hackers don't get
noticed until they make some noise. On the other hand even below average
programmers who hop jobs often are paid real good packages. The way companies
think of it is, that in any project if there say a x people. x-80% people work
well, and are expected to compensated for the work of x-20% people. At the
project level when the productivity data is measured, it turns out productive
people have averaged out the unproductive data of the other crowd. So on a
company wide policy basis a uniform hike applies, since data suggests
productive was around industry average. The actual work of productive guys
never gets displayed at all. This is just day light fraud, and a very
scandalous way of rewarding people.

------
invalidOrTaken
One option I haven't seen anyone mention is freelance development, especially
at the higher end. This:

\--isolates the effort/product of one person, allowing for easier measurement

\--puts the burden of estimating productivity on the programmer, who, if he is
as experienced as he says, is probably best equipped to judge his own
productivity (as manifest by what he charges)

------
clueless123
It is a classic case of The Vulcan vs the Ferengi.

Programmers are fact base thinkers,unfortunately this skill makes us poor
negotiators.

------
markmypy
I have worked with someone who was 10x more productive than the rest of the
team. His contribution was acknowledged, he had a fancy job title and he was
paid more. There were 2 issues with this guy:

1) Since he had privileged treatment his colleagues did not like him! 2) He
did write code a lot faster than anyone else, but his code was not optimized.
Since he was the 'head of development' (or something like that) pointing out
that his code was not optimized did not have any effect (he was really
stubborn). So we shipped the code fast, usually we would get a complaint by
the customer, re-evaluated the code, optimized it and send it back.

I would say that his code writing productivity did not seriously effect the
overall development cycle of the project. As many of you said, there is no
systematic way of measuring productivity!

------
mikepk
This is the animated TED talk that I referenced before on motivations. I'm
sure you've seen this before, but still interesting in this context:
<http://www.youtube.com/watch?v=u6XAPnuFjJc>

------
known
Writing software != Selling software

------
cjbprime
Huh. My first thought was "Maybe the reason we don't pay some programmers 10x
what we pay others is that the ones who get paid less would quickly find out
and then get resentful".

I don't find the "paying proportionally doesn't happen because sometimes the
best way to program is to not write much code" argument very convincing; what
about the times when the best way to program _is_ to write a lot of new and
correct code?

------
vipivip
Should hr be blamed for hiring mediocre programmers?

~~~
elliottcarlson
As 83457 put it - HR should never be tasked to hire a programmer. Same with
recruiters. You can give them a set of criteria to weed out people by (they
shouldn't be sending you .net resumes if you are a PHP shop) but the end task
of choosing a developer should be vetted by someone who can determine if the
candidate is good. Either a technical director (with actual knowledge) or by
peer review from your current programmers.

If you don't have any programmers and are making a first hire, ask for code
samples and have someone you know that is a developer review them. If you
don't have any programmer friends then you need to spend some more time on HN
or at local meetups :)

------
wild_eep
The problem with this entire article is the very first sentence. "The most
productive programmers are orders of magnitude more productive than average
programmers."

Many of the comments here conclude that it's difficult, if not impossible, to
quantify programmer productivity.

So, if productivity is essentially unmeasurable, how can the initial sentence
of the article be true?

------
luke_osu
When you work for someone else you don't get to make the rules. The quicker
people realize that, the better off they will be.

------
iamelgringo
Your startup is your new resume. Extremely productive programmers are being
paid $1M a head in a talent acquisition plus salary with a 4 year lock in.
That means that highly productive programmers are work $350k a year.

All you have to do is build your startup and get acquired to get that salary.
:)

------
cwp
Actually, I think programmers _do_ get paid in proportion to their
productivity. Roughly, anyway.

------
jimwise
Decades in, I don't think we have a meaningful (or at least measurable)
definition of what productivity actually _means_ (the article touches on
this).

So it's hardly surprising that we don't pay in accordance with something we
still don't know how to measure...

------
raghava
Am I the only one to think that it's time some asked the question, 'why are
mediocre/sub-standard (and even non-programming) developers still being paid a
good programmer's salary?'

Am I wrong in thinking this way?

------
petercooper
I hope he's not paid in proportion to his font size. Ouch. 9pt or 10pt Times
Roman isn't fun..

