User: Password:
|
|
Subscribe / Log in / New account

1000x

1000x

Posted Aug 7, 2008 2:56 UTC (Thu) by ncm (subscriber, #165)
Parent article: Kernel Hacker's Bookshelf: The Practice of Programming

A friend of mine collected and analyzed statistics on a six-month crash project involving some
500 programmers.  At project end, fully half the code delivered had been written by just one
of them.  This programmer, whom I shall call Per because that's his name, is humble about his
skills, because he knows someone else who codes ten times as fast, and wears out two keyboards
a year.

When the difference between a mediocre programmer and the best is three orders of magnitude,
it argues for (1) paying way more for somebody closer to the latter, and (2) figuring out some
way to identify him or her.  Fortunately, our distinguished author, Ms. Henson has identified
herself for us.  Others working in Free Software distinguish themselves, to varied but
measurably visible degrees, in their public work.  

Curiously, the pay scale seems to be logarithmic; it is vanishingly rare to find a star
programmer of Per's or Val's caliber paid more than three times as much as an ordinary
programmer.  I take that as evidence that software development management has not yet attained
a stone-age level of sophistication.


(Log in to post comments)

LOCs is not everything

Posted Aug 7, 2008 7:33 UTC (Thu) by khim (subscriber, #9252) [Link]

I know a guy who spend two months to add five lines of code to the project. Of course these five lines fixed nasty race condition which was only triggered under high load and was very hard to see from just looking on the code. And it's very easy to write a lot of trivial code. But yes, productivity of different programmers vary much bigger then their salary...

1000x

Posted Aug 7, 2008 18:47 UTC (Thu) by vmole (guest, #111) [Link]

it is vanishingly rare to find a star programmer of Per's or Val's caliber paid more than three times as much as an ordinary programmer.

That's because it's directly against standard accepted management theory to accept that workers are anything but interchangeable cogs.

1000x

Posted Aug 7, 2008 21:26 UTC (Thu) by nix (subscriber, #2304) [Link]

By extension, if a programmer should implement something requiring 
algorithms more complex than can be explained in three lines of crude 
pseudocode, such that a random monkey pulled off the street can't 
understand them in five minutes, it's the fault of the person who 
implemented that algorithm.

(I get this all the time. I ignore it. The proposed replacement 
algorithms, if any are provided, are invariably brittle, slow, and don't 
work.)

1000x

Posted Aug 7, 2008 21:42 UTC (Thu) by alankila (guest, #47141) [Link]

In Finland, we have the concept of "donkey's bridge" which means a way to move discussion to
(un)related topic across a method that might superficially seem related but in reality is not.
I do not know where it is coming from, and I digress.

I feel like pointing out a man called Steve Yegge who tends to have useful bits of information
in his blog, especially for programmers. Give it a try, maybe his style works for you.

1000x

Posted Aug 14, 2008 6:58 UTC (Thu) by ketilmalde (guest, #18719) [Link]

> In Finland, we have the concept of "donkey's bridge" which means a way to 
> move discussion to (un)related topic across a method that might 
> superficially seem related but in reality is not. I do not know where it 
> is coming from, and I digress.

http://en.wikipedia.org/wiki/Pons_asinorum

1000x

Posted Aug 8, 2008 7:57 UTC (Fri) by ekj (guest, #1524) [Link]

That's not special to programming. It goes for all creative problem-solving skills. More true
the more creative, more analytical the work is though.

A skilled person will clean a room in half the time, and the result will be better.

But a skilled mechanic will sometimes listen to a car-engine for 10 seconds, twist one screw,
listen to it again, and know what the problem is, whereas a clueless one might spend a day
searching for the problem.

It's rare that pay scales with performance. And it'd probably be a bad thing for society
overall if it did. It should probably differ MORE than it does though, but that would require
management to be able to actually recognize skill, which is a tricky proposition.

1000x

Posted Aug 8, 2008 15:33 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

Curiously, the pay scale seems to be logarithmic; it is vanishingly rare to find a star programmer of Per's or Val's caliber paid more than three times as much as an ordinary programmer. I take that as evidence that software development management has not yet attained a stone-age level of sophistication.

It isn't actually stone-age; it's middle-age. In fact, you don't have to look at how much code a person produces to see the phenomenon; we don't even pay most engineers proportional to how much time they put in. Salaried employment is right out of feudalism, and while I understand how it fit into the economy of the middle ages, it always amazes me that we still use it today.

But there must be something going for it, because otherwise it would not survive competitively.

1000x

Posted Aug 19, 2008 18:11 UTC (Tue) by job (guest, #670) [Link]

Why does it follow that a steep pay scale is somehow more sophisticated?

I would believe that is a dangerous path. As soon as you measure productivity as a one
dimensional variable (the pay rate) you open for all sorts of possibilities to cheat. Lines of
code? Easy, write bad code. Bugs? Easy, write nothing. Fixed bugs? Easy, write buggy code in
the first place. As soon as you reduce productivity to a single value you will start getting
results reflecting that.

Measuring productivity has been a hot topic since the seventies and so far nothing of value
has been produced by doing it. It's just not that simple. If it were, your boss should also be
compensated according to his/her abilities, and how do you measure THAT? And even if you pull
off this impossible stunt, I believe you would find that the best creative people in this line
of work require a lot more complex incentive than money.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds