Wednesday, July 13, 2011

Concentration Matters

Dear Blogspot,

I think I can speak for many programmers when I say that Concentration Matters... a lot. When coding, we often have to wrap our minds around some long train of data marshaling, subtle bits of transformation broken into discrete functions, and balancing the side effects of doing something in one process on some other process. This requires our brains to bring largish amounts of information into the fore of our mind and KEEP it there while we code, so that our inputs can be have a proper coarse plotted towards the desired output despite the complex set of shoals ahead. This act of keeping this broader information in mind, steering the line of code being written at the moment, while plotting the coarse immediately ahead is what I call "concentration". It requires a degree of patience and discipline. A flighty mind need not apply.

Imagine a widget machine that requires a long warmup, but slowly becomes more productive at generating widgets of higher quality over time as it reaches its peak rate in both speed and quality. Now imagine some idiot coming along and turning it off and on every 20 minutes. Welcome to the real world of software development.

For developers, these breaks of concentration take many forms: meetings (especially the impromptu sort), questions, favors, or even social visits. It is especially bad when the interruption comes from another developer who, in trying to maintain his own train of thought, interrupts another developer with a question. As an aside, I would not count developer initiated events such as web surfing, or writing blog entries in this list, since the concentration break has inner costs that sufficiently incentivizes against it. Moreover, it can be hard for non-developers to grasp this problem sufficiently to appreciate it. In my experience, few tasks in software engineering outside of writing code requires a level of concentration that makes it a serious matter to afford no mental breaks.

The inner costs I mentioned creates perverse incentives that adds to the general loss of productivity. After all, if you know you will have to bear the inner cost, and you know your productivity will be lower, why turn the "coding machine" back on at all? Better to wait until you have reasonable expectation of some period of quiet. For those of us who find the inner costs of the interruptions most jarring, better yet to work after everyone else has gone home. (Is this why so many programmers are also "night owls"? )

Occasionally, management will see the wisdom of this insight and take steps to mitigate the damage in order to increase productivity. Instituting "No meeting days", or "No interruption" periods during the day are interesting, if failed, attempts. Other members of the overall team, from QA to management all require information to effectively do their jobs; information that is inconveniently concentrated in the mind of the developer. In other words, attempts to fix this problem will invariably affect the productivity of others and the company overall. By how much? Who knows! Nobody bothers to measure.

So, Blogspot, once again I've proven a useless whiny writer, contemplating problems for which I have no proffered solution, except that these matters should be measured, and a degree of mitigation proper to its overall effectiveness instituted.

I would get right on that, but everyone is headed out to lunch, and I've work I can do now...