Friday, 5 April 2013

Order of magnitude variations in developer productivity .... for the same person!


I have been in situations where I was (very nearly) 10x more productive than anybody else in the team, as well as in situations where I was (frustratingly) considerably less productive than those around me. Looking back at the last decade or so, I can definitely see periods where my productivity dipped, as well as periods where I was able to maintain consistently outstanding results. The variance is astonishing and shocking.
Over a shorter time-scale, programming, like any other creative endeavour, has tremendous temporal performance-volatility. Performance "in the zone", when I am in a mental flow-state of high concentration is orders-of-magnitude better than when sitting in the doldrums, unable to perceive or engage with the natural semantics of the problem domain. Writers block (to an extent) happens to programmers, too.
There are a number of reasons for these variations:
Firstly, over the long term, sampling effects play a part in (relative) performance. You can expect the quality and dedication of the team that you are working with to vary significantly, so as you move from team to team your baseline for comparison swings all over the place.
Secondly, experience and tools. You are never going to perform as well when you are learning as you are going - I am easily an order of magnitude more productive when using tools with which I am familiar than when trying to learn something new. (But, as per the technologist's typical Catch-22, you need to always be learning something new to stay relevant)...
Thirdly, personal circumstances:- commuting distance, family obligations, (small children), illness, living conditions. All of these have an impact on day-to-day mental alertness and ability to get "into the zone", although perhaps to a lesser extent than the other factors in this list.
Fourth, team dynamics. Some of my highest levels of productivity have been when operating as part of creative, collaborative partnerships, with another highly engaged team member to bounce ideas off, and to debate the merits of various approaches. This produces a creative dynamism that both improves the quality of the end product, and promotes active engagement in the process by both members of the "dynamic duo".
Finally, the big one: enthusiasm and engagement. This is really about organizational dynamics, leadership and psychology and is perhaps the hardest aspect to understand and control. For a programming task where attention to detail and mental engagement with complex systems is critical, the level of enthusiasm and engagement in the problem domain is critical for performance. In those roles where I have "lived the job", and spent every waking moment turning the problem-at-hand around in my head, dreaming about it when I fall asleep at night, I have obviously and significantly outperformed, in comparison to those roles where the job feels like an endless (and pointless) grind with no end in sight. You have to believe in the mission to perform, and that is as much an (external) function of leadership as your own (internal) reserves of fortitude and grit.
In summary, the biggest effect on (long term) performance is probably the existence of total, absolute and life-consuming dedication to the task at hand, as it promotes rapid learning and extended periods in flow-state. Inspirational leadership and creative partnerships do an enormous amount to encourage and support this level of engagement in the work environment, whilst suitable domain expertise and knowledge helps to reduce frustrations and remove barriers to progress. Finally, an absence of confounding factors and distractions in the out-of-work environment also helps.
So, a lot of it is how the job, the organization and the developer fit together. The 10x thing is not about innate skill (except in a statistical sense). As a leader, there are definitely a large number of things that you can do to increase the probability that members of your team will perform at their peak.