Pairing uses more of your brain

I have a theory that pair-programming is an acceptable alternative to talking to yourself.

I’ve come to this conclusion while working in pairs with people in the team for the greater part of the last few months. I was wondering why, on a purely qualitative level, our team seems to get more out of its developers when they work as half of a pair, compared to when they work solo. We feel that we can work more carefully and more thoroughly in pairs, and we’ve noticed that our pairing days feel more intense. We’re usually more tired at the end of them, than on days when we’ve been working by ourselves.

I guess the basis of my theory is that we inevitably use more of our brains when we pair. It would take some MRI equipment to be truly scientific in verifying this. Probably beyond our development budget. So instead I’ll just talk about why this might be.

Suppose I’m sitting by myself in my study at home, quietly writing some code. If I were a neuroscientist, I would list the bits of my brain I’m using for this task, including parts of the cerebral cortex for expressing my thoughts in the language of the software, the temporal lobes for memory, the parietal lobes for formulating mental pictures and nonverbal ideas, and coordinating hand-eye movements, and so on.

As time passes, I get deeply involved with what I’m doing. If I had a tape recorder in the room I would notice an amusing change in my behaviour. I start talking to myself.

I’m confident this is no reason suddenly to go check myself into the nearest mental health facility. In fact many people do this, if only for a moment, before they look round the office and remember they’re not actually by themselves.

If I start talking to myself while coding, it shows my brain has started to engage other linguistic and speech-related parts of itself, namely the Wernicke and Broca areas in the left hemisphere. It’s almost as if my brain is chipping in more resources to help out with my coding task. And if I’m totally honest, talking aloud like this does help. I seem to be able to think more clearly about a problem if I can start talking about it, if only to the walls.

Of course, these days I do all my real work in an office. It’s an open plan office in which I’m surrounded by people. I’m not about to start talking to myself. I would be an awkward distraction, and everyone would think I was a loon. So when I’m working solo in the office, Broca and Wernicke can’t get involved, and I have to use less of my brain.

Except, if I’m pair programming, I need those linguistic and speech areas, so I can talk about what I’m doing, and listen to the inflow of ideas from my pairer. I can’t pair without them.

It would be wrong to consider the brain as one big fatty coding engine, that the more of it you could deploy for software development, the faster you could churn out product. But I do think involving more of the brain by introducing a spoken interactive element is a big improvement on working in silence in isolation. Especially as ours is a typical open plan office where there is no silence. If coders can’t have silence, better the primary noises going into their head are their pairer talking about what to type next.

One accusation often levelled at pair programming is that it wastes programmer resources: surely the team could complete more tasks in a development cycle if they paired less? I would love to try and measure whether or not this is true. Without a measurement, developers resort to the usual defensive arguments that pairing improves code quality, distributes knowledge over the team, and so on. Meanwhile, I’m happy in the opinion that if need to get more work done, pairing seems to be a good way of getting the most out of my brain while not sounding like a crackpot.

One thought on “Pairing uses more of your brain”

  1. I like this way of explaining some of the benefits of pairing. It meshes really well with a theory of programming as linguistic development.

    It was said once (and many times since then, I believe it started at AT&T Bell Labs) that software library development is language development. So the more you get a chance to engage the language processing portions of your brain, the more richness of expression, meaningfulness, correctness, and completeness you’ll achieve in that language that you are creating.

    This way of thinking also meshes well with the modeling approach to design. Create a model (a language) that expresses your domain, and everything falls into place easily because you can simply say what the problem and solution are without having to fall back to bits, bytes, abstract data structures, and so on.

    Another way of understanding the importance of language in programming is the Saphir-Whorf Hypothesis (http://en.wikipedia.org/wiki/Sapir%E2%80%93Whorf_hypothesis). The implication is that without fully engaging our language processing and development areas we would always be at a disadvantage in problem solving. Simply stating the problem and solution would be difficult if not impossible.

Leave a Reply

Your email address will not be published. Required fields are marked *