Developer Productivity by Mark Stone

April 2024. My friend Christian Cameron writes books faster than I can read them. I kept pace through his first 20 or so novels, then gave up. His publisher doubtless sees him as a highly productive author, but as consumers of his product we wouldn't judge the product's worth by the speed with which it was produced. For example, it makes no sense to say his best book was the one he wrote the fastest. For artists in general, we don't equate the quality of their work with the speed by which it was produced.

My friend Tracie Rodriguez runs a sub-3 hour marathon. As runner, the quality of her work is entirely about speed, and she is crazy fast. For athletes it is natural to equate productivity with performance: being the fastest, being the strongest, etc.

Are software developers more like artists, or more like athletes?

I claim developers are more like artists. Their best work is not necessarily their fastest, and pushing for faster work risks jeopardizing quality. Developers, like artists, also benefit from longevity. We expect their craft to improve throughout their career, rather than reaching some inevitable diminution, as athletes do.

How, then, can we improve developer productivity? This question has internal and external answers.

Internally, developers can manage career growth by making the output of their cognitive effort as efficient as possible. For example, using an IDE generally removes cognitive toil over using a plain text editor. Similarly, using an AI helper like Copilot can remove cognitive toil. Developers can deepen and broaden their knowledge, thus making a wider set of solutions cognitively accessible, instead of requiring a research effort. Learn new languages and frameworks. If you didn't come from a computer science background, take a course in Data Structures and Algorithms; the foundations of most efficiency secrets are in that class.

Externally, can we remove cognitive distractions. My work as an agile practitioner is centered around this idea. Switching costs are high, so minimize context switching imposed on developers. Fewer meetings, and only those with clear focus and well-defined outcomes. Dependency questions to another team should have a rapid response. Rely as much as possible on asynchronous communication, allowing developers to queue response to interrupts for natural break points in their work. Write requirements for your audience -- the developer -- so they have clear expectations about the work.

What we can't do is urge developers to simply write code faster. That's not how developer productivity works.

Oh, and everyone should read Christian Cameron's novel "Washington and Caesar". It's his best work, and a true classic.

Add / view comments.