Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why programmers are not paid in proportion to their productivity

johndcook.com

Post reply on HN
Print view View original

91–100 of 133 posts

Re: Why programmers are not paid in proportion to their productivity

#91

Post by scott_s »

rdouble wrote: post #86
zackattack wrote: post #74

Earlier quoted context omitted.

I'm skeptical. What evidence do you have for this? Maybe some people who have a better start (those who are "naturally" talented) receive better instruction, or are more inclined to practice more often.

Programming ability is more like athletic ability than most people want to admit. Some guys just get better, faster. Some guys can't ever break certain plateaus, no matter how hard they try. In golf, it's probably possible for anyone to go from a duffer to a scratch golfer. But it might take 20 years of work for someone who isn't set up with the right natural gifts. Quality and amount of instruction and practice will…

I'm actually skeptical of "natural ability," and I find it... a cop-out to ascribe learning rates to it. I think presence of mind matters. All practice is good, but some practice is better than others. People who are continually conscious of their performance, and who actively try to figure out how to improve will probably learn faster than someone who practices passively and hopes to improve "by accident."

Re: Why programmers are not paid in proportion to their productivity

#92

Post by rdouble »

scott_s wrote: post #91
rdouble wrote: post #86

Earlier quoted context omitted.

Programming ability is more like athletic ability than most people want to admit. Some guys just get better, faster. Some guys can't ever break certain plateaus, no matter how hard they try. In golf, it's probably possible for anyone to go from a duffer to a scratch golfer. But it might take 20 years of work for someone who isn't set up with the right natural gifts. Quality and amount of instruction and practice will…

I'm actually skeptical of "natural ability," and I find it... a cop-out to ascribe learning rates to it. I think presence of mind matters. All practice is good, but some practice is better than others. People who are continually conscious of their performance, and who actively try to figure out how to improve will probably learn faster than someone who practices passively and hopes to improve "by accident."

I'm skeptical, too, but I don't think anyone's yet figured out a unified theory of ability.

Re: Why programmers are not paid in proportion to their productivity

#93

Post by maddalab »

tigerthink wrote: post #89

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…

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.

Re: Why programmers are not paid in proportion to their productivity

#94

Post by oujheush »

rdouble wrote: post #92
scott_s wrote: post #91

Earlier quoted context omitted.

I'm actually skeptical of "natural ability," and I find it... a cop-out to ascribe learning rates to it. I think presence of mind matters. All practice is good, but some practice is better than others. People who are continually conscious of their performance, and who actively try to figure out how to improve will probably learn faster than someone who practices passively and hopes to improve "by accident."

I'm skeptical, too, but I don't think anyone's yet figured out a unified theory of ability.

No one's figured out a grand unified theory of Physics either but they still have a lot more useful conclusions and solid research than we do on ability.

Re: Why programmers are not paid in proportion to their productivity

#95

Post by ggruschow »

Poiesis wrote: post #31
ggruschow wrote: post #14

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…

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…

I've done performance based pay for programmers both at the individual and group level. It adds a lot of non-obvious problems. I don't believe it improves happiness, retention, or productivity in the long run†.

Most companies theoretically already do performance based pay, but just at two levels:

  Level 1 pay: $salary
  Level 2 pay: $severance
There's usually a lot of room for improvement. If they can't get it right for 2 levels, they shouldn't look to fix it by adding more.

If you've got a big productivity range and a small pay range, you don't have to address it by expanding the pay range. You can focus the productivity range instead, and get lots of side benefits. Let the people who aren't performing well find another job.

Remember there's more to comp than just wages and bonuses too. Sometimes other things can address perceived needs.

___

† I'm assuming most good employees will be around 2 years or more. If you don't expect that, that changes everything.

Re: Why programmers are not paid in proportion to their productivity

#96

Post by nandemo »

dagw wrote: post #78
nostrademons wrote: post #53

Earlier quoted context omitted.

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 -…

In the real world the amount someone is willing to pay for your work is greatly influenced by how it is marketed and sold. I known some great programmers whom I suspect would fall flat on their face if forced to start their own company, but when placed in a team where they can focus on their strength can produce great things. So while it might be good way to measure the productivity of companies it isn't a great way…

In the real world the amount someone is willing to pay for your work is greatly influenced by how it is marketed and sold.

Yes. An Indian programmer could earn (say) $15k at home, 40k if she goes to Japan, and 80k in Silicon Valley. All doing the "same" job.

Re: Why programmers are not paid in proportion to their productivity

#97

Post by ggruschow »

Psyonic wrote: post #55
Poiesis wrote: post #31

Earlier quoted context omitted.

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…

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.

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.

Re: Why programmers are not paid in proportion to their productivity

#98

Post by oujheush »

hvasishth wrote: post #59
DougBTX wrote: post #46

Earlier quoted context omitted.

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)

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…

What about someone who works 10-12 hours and accomplishes the most tasks? I think you have to understand the corporate mindset without abandoning your black-belt coder-fu. Yes, you have to emphasize how difficult what you did was. You have to point out what you've accomplished. And tie yourself in directly with producing specific pieces of revenue wherever possible.

But this will all be helped if you can program well. And if you want to play office politics, it'll be useful to have the ability to accomplish someone else's job in half the time, if you really can.

Re: Why programmers are not paid in proportion to their productivity

#99

Post by DenisM »

nostrademons wrote: post #67
raganwald wrote: post #66

Earlier quoted context omitted.

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 m…

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 programmer…

As the starter of the thread branch I hereby endorse everything nostrademons wrote here. I couldn't have said it better myself even if I tried hard.

Re: Why programmers are not paid in proportion to their productivity

#100

Post by DenisM »

Confusion wrote: post #76
DenisM wrote: post #45

Earlier quoted context omitted.

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.

But it is not a measure of the productivity of a programmer . It may be a measure of the productivity of an entrepreneur, but that is not what this article is about.

Therein lies a subtle indicator as to what is the value-add in the modern economy. Any other measure of productivity is prediction of the this one (at best) or cargo-cult metric (aka vanity metric) at worst.
Post reply on HN