5 ms·

Show me how to measure productivity and I'll find a way for the 10x more productive programmer to earn 10x the compensation. I agree with the OP that the probl

Show me how to measure productivity and I'll find a way for the 10x more productive programmer to earn 10x the compensation. I agree with the OP that the problem here is that it is not easy to measure productivity. http://github.com/raganwald/homoiconic/blob/master/2009-02-12/a_question.md http://github.com/raganwald/homoiconic/blob/master/2009-02-1...

samuel 17y ago
It's worse than that. There is a standard way of assesing programmers productivity and is the worst it could be: kLOC's.
- raganwald 17y ago
  > Measuring programming progress by lines of code is like measuring aircraft building progress by weight. --Bill Gates. My favourite consequence of measuring productivity by the line is to ask how much I owe my employer when I spend a day eliminating redundancy and thus contribute negative lines of code.
- wgj 17y ago
  Actually, I've always seen kLOC as a divisor: defects/kLOC, branches/kLOC, etc. Even metrics like functions/kLOC are useful, if you believe in small functions.
  - TeHCrAzY 17y ago
    We use stats like this to help us gauge the project as a whole, but its considerly likely to be useless for measuring individuals productivity etc.
- nostrademons 17y ago
  Basically every programmer I've worked with agrees that kLOC is a terrible way of assessing productivity. I think it's only "standard" in the stupid section of the industry (which, alas, is much bigger than it should be).
DenisM 17y ago
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.
- raganwald 17y ago
  That is roughly equivalent to saying that the true measure of an employee's productivity is their salary. What are you measuring?
  - nostrademons 17y ago
    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 - so yeah, the true measure of an employee's productivity is almost their salary. (It's actually revenue / employee / hour, so if an employer keeps most of the money as profit, it's still productivity. That's why the grandparent suggested "start your own consultancy".)
    - raganwald 17y ago
      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 measure of programmer productivity and then ask why the marketplace is so inefficient that economic productivity does not correlate with programmer productivity.
      - nostrademons 17y ago
        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 programmers who would easily be making 100x more as startup founders are instead making 50% more, with the balance going to the employer? After all, if we measure by revenue generated for the employer, I'm in at least the 7 figures, within an order of magnitude. And I doubt Aaron etc. were making all that much in salary when they were Google employees either. I suspect the answer to this has to do with risk allocation. Because technology markets tend to be winner-take-all, there's a lot of variance in productivity that's not the result of the coder's actions. In other words, it comes down to luck, being in the right market with the right product. You can work hard at the wrong thing and still produce nothing of value, despite being smart and dedicated. When you sign on as an employee, your employer agrees to take on the risk that you'll work hard and still nothing will come of it. And in return, they get nearly all of the upside if your hard work does result in something great. I suspect that the 10x more productive figure is a result of sample bias: when you look at what people have done, there are some folks whose projects were 10x more useful than what other people have done. All the people who worked equally hard and produced equally large amounts of code are lumped into the "not productive" category, because in hindsight, their projects weren't all that useful. If you try to predict, a priori, who the 10x coders are, I bet you'll have a much harder time. If you don't, you have a sterling future ahead of you as a venture capitalist.

samuel 17y ago

It's worse than that. There is a standard way of assesing programmers productivity and is the worst it could be: kLOC's.

raganwald 17y ago
> Measuring programming progress by lines of code is like measuring aircraft building progress by weight. --Bill Gates. My favourite consequence of measuring productivity by the line is to ask how much I owe my employer when I spend a day eliminating redundancy and thus contribute negative lines of code.
wgj 17y ago
Actually, I've always seen kLOC as a divisor: defects/kLOC, branches/kLOC, etc. Even metrics like functions/kLOC are useful, if you believe in small functions.
- TeHCrAzY 17y ago
  We use stats like this to help us gauge the project as a whole, but its considerly likely to be useless for measuring individuals productivity etc.
nostrademons 17y ago
Basically every programmer I've worked with agrees that kLOC is a terrible way of assessing productivity. I think it's only "standard" in the stupid section of the industry (which, alas, is much bigger than it should be).

DenisM 17y ago

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.

raganwald 17y ago
That is roughly equivalent to saying that the true measure of an employee's productivity is their salary. What are you measuring?
- nostrademons 17y ago
  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 - so yeah, the true measure of an employee's productivity is almost their salary. (It's actually revenue / employee / hour, so if an employer keeps most of the money as profit, it's still productivity. That's why the grandparent suggested "start your own consultancy".)
  - raganwald 17y ago
    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 measure of programmer productivity and then ask why the marketplace is so inefficient that economic productivity does not correlate with programmer productivity.
    - nostrademons 17y ago
      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 programmers who would easily be making 100x more as startup founders are instead making 50% more, with the balance going to the employer? After all, if we measure by revenue generated for the employer, I'm in at least the 7 figures, within an order of magnitude. And I doubt Aaron etc. were making all that much in salary when they were Google employees either. I suspect the answer to this has to do with risk allocation. Because technology markets tend to be winner-take-all, there's a lot of variance in productivity that's not the result of the coder's actions. In other words, it comes down to luck, being in the right market with the right product. You can work hard at the wrong thing and still produce nothing of value, despite being smart and dedicated. When you sign on as an employee, your employer agrees to take on the risk that you'll work hard and still nothing will come of it. And in return, they get nearly all of the upside if your hard work does result in something great. I suspect that the 10x more productive figure is a result of sample bias: when you look at what people have done, there are some folks whose projects were 10x more useful than what other people have done. All the people who worked equally hard and produced equally large amounts of code are lumped into the "not productive" category, because in hindsight, their projects weren't all that useful. If you try to predict, a priori, who the 10x coders are, I bet you'll have a much harder time. If you don't, you have a sterling future ahead of you as a venture capitalist.