Pairing Fatigue

10 June 2012

I spent twelve months pair programming every day on the project that Chris Turner describes here: > The conclusions that I have had to draw is that working in a paired environment is more mentally tiring that working alone or individually within a team. Compared to the rest of the organisation, the teams Chris and I worked on were extremely high performing. Each team used slightly different technologies and were effectively autonomous, but our common value was pair programming on all production code.

I believe the teams produced far better code, a far better product and in far less time, than we would have done working as individuals. 

But my personal experience was similar to Chris’: Pair programming over an extended period of time is exhausting. 

At its most effective, pair programming requires a massively high level of empathy, concentration and commitment from two people. That effort has to be sustained for hours in order to get things done.

Being totally engaged with a task and effectively narrating your thought process is a mental workout like nothing I’ve ever experienced. Some days I got home from work and was unable to hold a trivial conversation; I was mentally exhausted.

In our team we rotated pairs almost every day. A change is as good as a rest, as they say, and that was certainly my experience. It’s tempting to stick in a pair when you’ve just had a really great day, but it’s better to quit while you’re ahead and let some fresh ideas into the work.

We tried to maintain an odd number of people in the team and a backlog of non-production work that could be done by a lone individual. CI build scripting, production support, spiking new ideas, fielding questions from other teams and being on hand to help out a pair in distress are all tasks that you relish after a week of intensive pairing. Some of our best solutions to tricky problems and most useful non-production tools were built by ‘The Loner’.

When pairing on RiverGlide work we use the Pomodoro technique, which requires its own discipline. We find it usually helps to reduce pairing fatigue.

Pair programming can seem like a shiny new tool, and it’s tempting to use it all the time. Because it requires such high levels of engagement and experience, use it sparingly in novice teams; a little goes a long way. As the team gains experience using the technique it should start to gain an intuitive feel for when not to use it.

Back off to give individuals a break and recharge. Lean on it even harder to really crank through difficult problems. In pressure situations I’ve found it’s almost always better to have a pair.