Live data from Hacker News

Why programmers are not paid in proportion to their productivity

johndcook.com

21–30 of 133 posts

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

#21
post #12

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?

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.

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

#22
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.

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

#23

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.

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.

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

#24
post #12

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?

http://www.reddit.com/r/programming/comments/9xmn8/what_we_a...

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

#25
post #8

Earlier quoted context omitted.

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

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

I don't know what you found through Google, but it was a bad description of the research cited in Peopleware. For a start the research they discuss was done in the 1980s, not the 1960s, and the methodology of their study was quite carefully done.

Read http://javatroopers.com/Peopleware.html#Chapter_8 for a much better overview of what Peopleware actually says. Of more interest than the productivity differences measured is the discussion of what factors were part of those productivity differences. Once you've read that, you may find the result much more believable. (There is a lot of detail in the book that is left out of the summary, but that's in the nature of what summaries are.)

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

#26
post #2

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…

i might be proud at first, but then i would be sad to think that others have failed so terribly and with so little guidance or wisdom. i would be saddened by my pitiful pride at a product so limited by its single creator.

my proudest moments are when i'm collaborating with such flow that no one knows exactly where each idea came from, and at the end we have a powerful, awesome product that none of us could have built alone, that is seemingly greater than the sum of its contributors. i can understand it, i can see some of my contributions, and yet it is greater than me. add some social good and purpose and then i'd feel me some good pride.

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

#27

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.

I wrote a crappy Python script one afternoon about eight years ago to address a client requirement discovered very close to implementation time. I think it's still running in a production environment -- at least I was told so as of a couple years ago. Was it great code? Nope. It split one file into four based on a particular column's value in a CSV.

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

#28
post #23

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.

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.

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.

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

#29
post #21
post #12

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?

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

This is a great piece of information, thanks. I always wonder at the shifting X, and am often perplexed that programmers who will take almost NOTHING for granted accept this as gospel truth without any corroborating sources.
Post reply on HN