I have run into a few articles on developer productivity this week. The articles have got me thinking enough to add a few comments of my own
First, one of the articles that I ran into was an 'ask' dialogue on Hacker News. There were a lot of ideas proposed but what I found particularly interesting was that as the dialogue progressed it become mostly about debugging. For some people debuggers were useless; all they needed was 'println'. Or maybe logs where enough. Or for some people once they had their test suite in place that was enough; if anything went wrong they could just look at their test suite and that took them to the root cause. And then of course some people found debuggers pretty valuable. Some statements that I thought were pretty valid:
Debuggers are useful for for figuring out unfamiliar code when just reading the code doesnt give one any insight.
Debuggers are also useful when something has gone wrong and all the tests look fine and all the code looks fine and one is looking for clues for where to start.
But overall given the topic of programmer productivity and the fact that the dialogue converged almost exclusively on debugging, my take was that however one likes to do it; program introspection is major enabling technology. We either automate the introspection (log, println) or we manually (debugger) do it. Code tends to behave differently than our best efforts end up writing and we don't end up very productive if we cant introspect our running code. Use all the tools you have at your disposal and use them well.
The second point about productivity I want to make is that there is not single productivity secret. In the 1980's the Japanese car producers were making major inroads in the US market and people would ask how can they make higher quality cars for a lower cost than US manufacturers? What's their secret? The secret was a multiple upon multiple small changes to how they produced cars that in the end added up to a big difference. And I shouldn't say added up -- rather to put it plainly multiple small improvements in productivity compound multiplicatively and they start to make a noticeable difference a lot faster then one would believe based on our natural intuitions. If one wants to be more productive expect to improve in a lot of small ways and then have those new habits compound at some point into a visible difference.
To be more productive one also has to become more productive where, as a developer, we spend the most time. Most of our time is spent trying to figure out how to implement a feature, trying to figure out what existing code does, and trying to figure out why code doesn't behave as expected. We spend very little of our time actually writing code, estimates are on the order of 10%. So one isn't going to be more productive by coding faster. One should concentrate one efforts where the fat is -- thinking and understanding. So write code that has clear architectural intent (macro level), and is understandable at the micro level as well. Write code that is as simple as possible. Write code with clear contracts that fails fast. And solve every problem once (see previous post on writing reliable code)
The final point is that productivity is ultimately limited by our primary constrained resource, time. One can make more time by automation, if there is enough payback from that. And to the extent possible, one can also use time well by identify tasks that are well thought out and have the most customer value. Don't just do work; do the 'right work'.
do your best, Marco
First, one of the articles that I ran into was an 'ask' dialogue on Hacker News. There were a lot of ideas proposed but what I found particularly interesting was that as the dialogue progressed it become mostly about debugging. For some people debuggers were useless; all they needed was 'println'. Or maybe logs where enough. Or for some people once they had their test suite in place that was enough; if anything went wrong they could just look at their test suite and that took them to the root cause. And then of course some people found debuggers pretty valuable. Some statements that I thought were pretty valid:
Debuggers are useful for for figuring out unfamiliar code when just reading the code doesnt give one any insight.
Debuggers are also useful when something has gone wrong and all the tests look fine and all the code looks fine and one is looking for clues for where to start.
But overall given the topic of programmer productivity and the fact that the dialogue converged almost exclusively on debugging, my take was that however one likes to do it; program introspection is major enabling technology. We either automate the introspection (log, println) or we manually (debugger) do it. Code tends to behave differently than our best efforts end up writing and we don't end up very productive if we cant introspect our running code. Use all the tools you have at your disposal and use them well.
The second point about productivity I want to make is that there is not single productivity secret. In the 1980's the Japanese car producers were making major inroads in the US market and people would ask how can they make higher quality cars for a lower cost than US manufacturers? What's their secret? The secret was a multiple upon multiple small changes to how they produced cars that in the end added up to a big difference. And I shouldn't say added up -- rather to put it plainly multiple small improvements in productivity compound multiplicatively and they start to make a noticeable difference a lot faster then one would believe based on our natural intuitions. If one wants to be more productive expect to improve in a lot of small ways and then have those new habits compound at some point into a visible difference.
To be more productive one also has to become more productive where, as a developer, we spend the most time. Most of our time is spent trying to figure out how to implement a feature, trying to figure out what existing code does, and trying to figure out why code doesn't behave as expected. We spend very little of our time actually writing code, estimates are on the order of 10%. So one isn't going to be more productive by coding faster. One should concentrate one efforts where the fat is -- thinking and understanding. So write code that has clear architectural intent (macro level), and is understandable at the micro level as well. Write code that is as simple as possible. Write code with clear contracts that fails fast. And solve every problem once (see previous post on writing reliable code)
The final point is that productivity is ultimately limited by our primary constrained resource, time. One can make more time by automation, if there is enough payback from that. And to the extent possible, one can also use time well by identify tasks that are well thought out and have the most customer value. Don't just do work; do the 'right work'.
do your best, Marco
RSS Feed