Flow, Pair Programming and Emotional Intelligence

July 22, 2008 § 6 Comments

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.

  • Gareth Jones

    Interesting O_o

    My experience of pairing is that is is extremely difficult to do well, and requires a very particular kind of person for it to be successful. Most developers are passive aggressive sociopaths and this makes ‘pairing’ with them painful at best.

    You usually end up with a few situations…

    A senior dev pairing with a junior dev. This can work ok, as long as the senior dev gets a break every few days to pair with someone who needs less coaching etc. Progress is not usually fast though. If you need to bring someone up to speed on a team this is an awesome way to do it.

    2 junior devs pairing together – oh no. Hope you have a good source control system.

    2 senior devs pairing together – best results in terms of productivity, however if the work is straightforward then the navigator is usually bored. Ping pong helps… but not much. If the work is not straightforward then it is difficult to get in ‘the zone’ having to constantly explain what you are thinking. You also get people pulling in opposite directions a lot on complex problems.

    Having paired with quite a lot of people in my time as a developer, I can honestly say I have enjoyed pairing with less than 5 people. The common characteristics of the people I enjoyed working with were: laid back, honest, sense of humour, humility, high technical ability. I posses none of those attributes. HAHA.

  • Mark Burnett

    Just because someone is in the ‘zone’ does not necessarily mean the code they are writing is any good.

    From a business perspective it probably means the code is built on a whole lot of assumptions that really should be challenged ( a pair is useful for this)
    From a technical perspective it probably means the code is very obvious and understandable to the person writing it, but probably not so obvious to any one else. Being regularly challenged by a pair would have probably sorted this out.

    To me, any process that stops people this kind of crap code is a good thing.

  • Liv

    As a Project Manager I’ve always found pairing interesting. I don’t mean that it shouldn’t happen but that there do appear to be some issues that arise. Yes it reduces the risk of ‘crap’ code and it is therefore a good thing. But shouldn’t we be concerned if there is (anecdotal at least) evidence to suggest that it has the potential to make people unhappy. From what I understand of John’s post he is seeking ways to reduce the risk of unhappiness not reduce the prevalence of pairing.

    In my 1-2-1s with team members I’ve had people talking about punching other people, hating other people and general grumpiness about those people that developers are pairing with (and this doesn’t usually centre around their level of aptitude more their personality – though when it comes to aptitude the grumbling can be, it seems equally vicious). When the challenges to a pair are so agressive it is no surprise that people are unhappy. I’ve struggled to find a solution to this – I can’t pass on 2nd-hand information so I try to help people to give feedback in a reasonably healthy way.

    I’ve been doing a lot of research recently on enabling people to fulfil their potential for happiness (particularly at work) and I read a lot about the benefits of effective feedback. One way to help this might be training, but that seems to be something that people forget quite quickly.

    How is it possible to maintain the kind of open discussions during the life of a project that would help people to discover their inner EQ and to have more effective conversations about how they are feeling during pairing?

    I have previously advised people to tell others when their feelings have been hurt – this has certainly helped me to move relationships to a higher level but this can’t be all that there is to it…

    Beware the next team that I work with because I am hoping to instigate meditation sessions – which have been studied and seem to help people to be more effective in their relationships. Furthermore they do something similar at Google – so it must be a good idea!

    Any other ideas to free the flow would be gratefully received!

  • http://blog.youngbloods.org/ Carl Youngblood

    One other thing that you haven’t considered is that pair programming helps people to avoid wasting time checking email, feed readers, slashdot etc. I believe that this factor alone makes it more productive than isolated programming.

  • Jeff Santini

    I like what Mark said. I know we all want to be in the zone, but I would like to see some evidence that the zone is more than just desirable, but is actually effective. Unless someone else can tell me that my zone time produced something impressive I am hesitant to give a unilateral judgement that it was a superproductive coding fest.

    But I may be a bit of a freak. I have actually enjoyed the vast majority of my pairing experiences. There have certainly been some frictional experiences, but they were a minority. That doesn’t mean there aren’t alot of ex-pairs of mine who were put off the idea because I was a lousy pair :)

  • http://www.betenglishfootball.com Ivana Kleindienst

    Nice Post. Genuinely it will support good deal of individuals.

What’s this?

You are currently reading Flow, Pair Programming and Emotional Intelligence at Pithering About.