I was involved in an interesting chat with some colleagues about the apparent incompatibilities between pair programming and being in the ‘zone’; a Zen like state where everything just clicks and one is able to perform seamlessly to their optimum ability given the present moment. From a developer viewpoint our egos become almost on autopilot as our hands reach out and tap away at the keyboard, the mind harmoniously serving up a variety of designs and strategies that may help us solve the problem at hand. We effortlessly approach excellence.
Psychologists refer to zone as ‘flow’. Daniel Coleman – author of Emotional Intelligence – describes flow as being “emotional intelligence at its best… the ultimate in harnessing the emotions in the service of performance and learning”. Emotions generate a plethora of thoughts for us, including distracting worries and concerns. Therefore having our emotions working for us enables us to be more focussed and to think more clearly and objectively about a specific problem.
Pair programming is a not stress free activity. Though it has been proven to raise productivity it does require more focus on the part of the developer – asking much more of them than were they coding solo. Being in a “pair” you are constantly required to explain your intricate thought processes to another person. You are challenged, and you have a responsibility to ensure that the person you are pairing with gets up to speed with the material at hand and that you are providing them with a progressive learning experience.
We need to appreciate that developers are humans, and sadly are not perfect coding punching-out machines. Pair-programming introduces an emotional burden on the developer. Thoughts such as how the other person in the pair is coping and performing are one of many, along with speculation as to what the other person is thinking… Are they frustrated that I can’t keep up? Are they worried I’m going too fast? Or worse still do they feel guilty for slowing me down? – a common concern as developers strive to be productive. In order to deal with these worries a whole new – totally justifiable – plateau of thinking opens up. The brain switches over from analysing the current software problem to instead work on strategies for making the pair more effective: ‘they have a need to see this area of the code-base as it will help them to contextualise the problem better… I want to get some “quick wins” to build our momentum as a pair, therefore it makes sense to pick off this little bit of low hanging fruit…’
I believe that whilst pair-programming has the capacity to inhibit flow, the emotional intelligence within us is the tool to help minimize the impact distractions have allowing us to closer reach a level of excellence on an individual level. EQ is essentially about being aware of our emotions and the impact they have on us – to realise when we’re worried, or when our frustrations are mounting. A higher EQ will not only help us to better meet our own needs, but it will give us more empathy and understanding to better meet the needs of the person we’re working with – to help us create a more effective “pair”. EQ is essentially about being aware, and the best thing about it is that unlike IQ it can be learned.
Lastly, I want to refer to the premise that “stress makes you stupid“. We underperform when our emotions run unchecked. I’ve seen first hand developers resigning from jobs they sought hard for because pair programming has been too much of a difficult experience. If we can improve our awareness of the distractions and difficulties pairing introduces – and in doing so our EQ – then we’ll likely make it easier for ourselves and the person we’re pairing with.