6 ms·

So... We can't quantify it or inspect it. We can't corroborate it. We can simply ask a programmer whether they are productive or not and trust them to answer f

So... We can't quantify it or inspect it. We can't corroborate it. We can simply ask a programmer whether they are productive or not and trust them to answer for themselves. And if Alice meets Bob on the street and they disagree over what makes them productive, there is really no way to settle the question. If Alice says she is more productive using Ruby than Python, but Bob says the opposite, we must trust that they are both right, and furthermore we can't really draw any conclusion. Because Charles may report that he is more productive with Ruby, or Python, or perhaps Arc, and again he is the only one who knows.

skawaii 18y ago
Could it be that productivity differs for each person? Maybe we can't have a productivity scale that is the same for everyone? Maybe it has to be applied personally? But then again, maybe if we drill down deep enough, we'd find common themes or aspects for why Alice feels more productive with Ruby and Bob with Python.
gruseom 18y ago
You're jumping to conclusions. I'm not saying this is the only possible measurement, I'm saying it exists and has some properties and not others. The absence of more "objective" measurements does not mean that programmers are talking nonsense when we discuss our own productivity. I think it is probably true, though, that the nonsense ratio tends to go up when we start discussing the productivity of others. That should tell us something.
prospero 18y ago
It's an unsatisfying conclusion, but is it really all that surprising? To coin a metaphor, a programming language is a shoe; only you know if it fits right. It might stretch out and become more comfortable over time, but it's not a debatable point that it's pinching your toes. Programming isn't a natural mode of thought, and programming languages aren't a natural mode of expression. I think it's unrealistic to expect that we'll ever find a universal best practice.
- raganwald 18y ago
  Your simile is what disturbs me: Often when programmers describe their productivity they are really describing their comfort level while carrying out programming tasks. However, when we use the word "productivity" in every other aspect of business, we are describing the production of output. We don't measure how the output is produced, or the subjective feelings of the producers. So what output are we discussing when we talk about productivity? Or are we using the word in a special way that has nothing to do with productiviy as it is used elsewhere?
  - deleted 18y ago
    [deleted]
  - prospero 18y ago
    Point taken on the simile. It's like that like never existed. As to the rest, I dunno. Let's consider the following scenario: every time you wrote something down on paper, there was a chance the paper would spontaneously burst into flame. There are strict, reproducible rules governing when the paper would and would not catch on fire. People go to school to learn these rules, which are varied and subtle. In this world I've described, is the best writer a person who can write the most essays that don't spontaneously combust? I feel like as programmers we think that because we can easily quantify whether something works, we can also quantify whether it's good. Or worse, that everything which doesn't burn away is essentially the same: just words on paper. It's simply not true. The fact that writing a program feels more practical than writing a novel doesn't change that.
  - dmoney 18y ago
    If it's possible to measure whole project success, at least it should be possible to see whether that is correlated with programmers' reported comfort levels (or some other reported emotional state, like excitement or fear).
  - yason 18y ago
    If there are two programmers and they both produce exactly the same output, but the differences are as follows: The first programmer has spent a lot more time in doing it (like 5x the second programmer) and carefully verified each line to make sure the code and algorithm are correct both conceptually and in practice, and tested that the code won't fail in any of the imaginable corner cases. The second programmer wrote it over the weekend, didn't test much else but merely cross-checked the code with a few working test cases similar to what the program will be used with for starters. He maybe followed his intuition to guide how to write or let his creative flow dictate the details of the program but he really hasn't had time to verify why. There seems to be no clear notion of which programmer was more productive. It all depends on what perspective the project is viewed. On the other hand, I believe there's always some absolute value underneath and productivity isn't entirely an subjective property. (Mandatory car analogy: If you want a Trabant and I sell you a Mercedes-Benz for the price of a Trabant and you still treat the car like a Trabant, the Mercedes is still better built regardless of how you extract value out of it.) When the project was deployed, both programs worked correctly as they are similar. The cost per line/token of the first programmer is five times the cost of the second programmer. On the other hand, had the second programmer undergone the same rigorous verification it would have taken 2x the time of the first programmer. Apparently the first programmer's code has a lot more value simply in being well-thought, and the programmer knows exactly why he has arrived in the solutions he wrote in the code. If the code broke the programmers would be on very different levels with regard to how to start debugging. On the other hand, the second programmer produced the same program in 1/5th of the time which may greatly please the management. However, the second programmer might easily become a grand failure in the next project as in this project he already reached the same solution if not by accident then at least by luck. Both programmers produced the same comments as they wrote it mainly for the future maintainers, as usual, instead of as a record of the whole mental process they experienced.
harpastum 18y ago
I agree that it is impossible to quantify productivity, but I believe it is not only possible, but _essential_ to inspect it. I like to think that most programmers enjoy being productive, and strive for increased productivity (rather than working just for a paycheck). I therefore also believe that programmers expend great effort over the course of their careers optimizing their work habits to maximize productivity. All programmers are different, but none of us is completely different from all others. There is much to be gained from examining what the others have learned in the process of programming. The danger in this is thinking that there is some objective Truth in programming productivity. So, Bob disagrees with Alice over what makes a programmer productive. Assuming both Bob and Alice are effective programmers, what we should really be examining are the ideas they have in common. For me, reading programming blogs from around the Internet gives me a giant mental Venn diagram--the ideas in the center are what I focus on.
whatusername 18y ago
sure we can quantify it.* Give Alice and Bob the same task. See who can do it faster / better. (obviously better can apply on multiple levels - but the tasks should clarify that. Performance, errors, scaling, maintenance, etc) At the end (maybe of 12 months to allow for maintenance) you'll have a quantifiable result saying that Bob is more productive than alice.. (for that task - and probably tasks like it) * I didn't say that it was easy or that we should spend that much time on a pissing match.
- gruseom 18y ago
  It sounds to me like what you're saying is that it's easy to measure productivity, all we have to do is measure quality. :)
  - JesseAldridge 18y ago
    Yes, we do need to measure quality. And maybe a simple metric wouldn't work, but a skilled programmer should be able to hold two results up side by side and judge for himself which is better. Controlled experiments with human judges seem like the best answer.
jerf 18y ago
It's like intelligence, or obscenity, or justice. The more you try to define it, the further it slips away from you. If you think you've got a universally-agreeable definition, you're wrong. But you know it when you see it. (Even if somebody else might not agree.) What are you gonna do? All the halfway interesting concepts in life work like that.
biohacker42 18y ago
I am not sure that we can't quantify it. Who's really tried? There's been a few research papers here and there, measuring the things that are easy to measure in a corporate environment. But who has both the incentive and the skills to measure a very difficult to quantify subjective experience? It is absolutely a very complex subjective experience, but it ain't magic. It IS very had to measure but it's not impossible just because no one's really tried yet.

skawaii 18y ago

Could it be that productivity differs for each person? Maybe we can't have a productivity scale that is the same for everyone? Maybe it has to be applied personally? But then again, maybe if we drill down deep enough, we'd find common themes or aspects for why Alice feels more productive with Ruby and Bob with Python.

gruseom 18y ago

You're jumping to conclusions. I'm not saying this is the only possible measurement, I'm saying it exists and has some properties and not others. The absence of more "objective" measurements does not mean that programmers are talking nonsense when we discuss our own productivity. I think it is probably true, though, that the nonsense ratio tends to go up when we start discussing the productivity of others. That should tell us something.

prospero 18y ago

It's an unsatisfying conclusion, but is it really all that surprising? To coin a metaphor, a programming language is a shoe; only you know if it fits right. It might stretch out and become more comfortable over time, but it's not a debatable point that it's pinching your toes. Programming isn't a natural mode of thought, and programming languages aren't a natural mode of expression. I think it's unrealistic to expect that we'll ever find a universal best practice.

raganwald 18y ago
Your simile is what disturbs me: Often when programmers describe their productivity they are really describing their comfort level while carrying out programming tasks. However, when we use the word "productivity" in every other aspect of business, we are describing the production of output. We don't measure how the output is produced, or the subjective feelings of the producers. So what output are we discussing when we talk about productivity? Or are we using the word in a special way that has nothing to do with productiviy as it is used elsewhere?
- deleted 18y ago
  [deleted]
- prospero 18y ago
  Point taken on the simile. It's like that like never existed. As to the rest, I dunno. Let's consider the following scenario: every time you wrote something down on paper, there was a chance the paper would spontaneously burst into flame. There are strict, reproducible rules governing when the paper would and would not catch on fire. People go to school to learn these rules, which are varied and subtle. In this world I've described, is the best writer a person who can write the most essays that don't spontaneously combust? I feel like as programmers we think that because we can easily quantify whether something works, we can also quantify whether it's good. Or worse, that everything which doesn't burn away is essentially the same: just words on paper. It's simply not true. The fact that writing a program feels more practical than writing a novel doesn't change that.
- dmoney 18y ago
  If it's possible to measure whole project success, at least it should be possible to see whether that is correlated with programmers' reported comfort levels (or some other reported emotional state, like excitement or fear).
- yason 18y ago
  If there are two programmers and they both produce exactly the same output, but the differences are as follows: The first programmer has spent a lot more time in doing it (like 5x the second programmer) and carefully verified each line to make sure the code and algorithm are correct both conceptually and in practice, and tested that the code won't fail in any of the imaginable corner cases. The second programmer wrote it over the weekend, didn't test much else but merely cross-checked the code with a few working test cases similar to what the program will be used with for starters. He maybe followed his intuition to guide how to write or let his creative flow dictate the details of the program but he really hasn't had time to verify why. There seems to be no clear notion of which programmer was more productive. It all depends on what perspective the project is viewed. On the other hand, I believe there's always some absolute value underneath and productivity isn't entirely an subjective property. (Mandatory car analogy: If you want a Trabant and I sell you a Mercedes-Benz for the price of a Trabant and you still treat the car like a Trabant, the Mercedes is still better built regardless of how you extract value out of it.) When the project was deployed, both programs worked correctly as they are similar. The cost per line/token of the first programmer is five times the cost of the second programmer. On the other hand, had the second programmer undergone the same rigorous verification it would have taken 2x the time of the first programmer. Apparently the first programmer's code has a lot more value simply in being well-thought, and the programmer knows exactly why he has arrived in the solutions he wrote in the code. If the code broke the programmers would be on very different levels with regard to how to start debugging. On the other hand, the second programmer produced the same program in 1/5th of the time which may greatly please the management. However, the second programmer might easily become a grand failure in the next project as in this project he already reached the same solution if not by accident then at least by luck. Both programmers produced the same comments as they wrote it mainly for the future maintainers, as usual, instead of as a record of the whole mental process they experienced.

harpastum 18y ago

I agree that it is impossible to quantify productivity, but I believe it is not only possible, but _essential_ to inspect it. I like to think that most programmers enjoy being productive, and strive for increased productivity (rather than working just for a paycheck). I therefore also believe that programmers expend great effort over the course of their careers optimizing their work habits to maximize productivity. All programmers are different, but none of us is completely different from all others. There is much to be gained from examining what the others have learned in the process of programming. The danger in this is thinking that there is some objective Truth in programming productivity. So, Bob disagrees with Alice over what makes a programmer productive. Assuming both Bob and Alice are effective programmers, what we should really be examining are the ideas they have in common. For me, reading programming blogs from around the Internet gives me a giant mental Venn diagram--the ideas in the center are what I focus on.

whatusername 18y ago

sure we can quantify it.* Give Alice and Bob the same task. See who can do it faster / better. (obviously better can apply on multiple levels - but the tasks should clarify that. Performance, errors, scaling, maintenance, etc) At the end (maybe of 12 months to allow for maintenance) you'll have a quantifiable result saying that Bob is more productive than alice.. (for that task - and probably tasks like it) * I didn't say that it was easy or that we should spend that much time on a pissing match.

gruseom 18y ago
It sounds to me like what you're saying is that it's easy to measure productivity, all we have to do is measure quality. :)
- JesseAldridge 18y ago
  Yes, we do need to measure quality. And maybe a simple metric wouldn't work, but a skilled programmer should be able to hold two results up side by side and judge for himself which is better. Controlled experiments with human judges seem like the best answer.

jerf 18y ago

It's like intelligence, or obscenity, or justice. The more you try to define it, the further it slips away from you. If you think you've got a universally-agreeable definition, you're wrong. But you know it when you see it. (Even if somebody else might not agree.) What are you gonna do? All the halfway interesting concepts in life work like that.

biohacker42 18y ago

I am not sure that we can't quantify it. Who's really tried? There's been a few research papers here and there, measuring the things that are easy to measure in a corporate environment. But who has both the incentive and the skills to measure a very difficult to quantify subjective experience? It is absolutely a very complex subjective experience, but it ain't magic. It IS very had to measure but it's not impossible just because no one's really tried yet.