Eleanor Mollett

Eleanor Mollett

What is ... pairing

What is it

Working in pairs on the same thing at the same time while sat together or on a call together.

Why do you need to know

You might think it looks inefficient, but it is a great way to improve quality, upskill developers, and can actually speed up delivery.

A bit more

Anyone can pair, developers can pair together, or they can pair with testers or designers. Pairing principles are great for the whole team regardless of role. You might find it useful to pair on writing documentation or presentations.

When developers pair, they often have a 'driver' and a 'navigator'. The driver is typing, and writing the code, while the navigator is thinking about what needs to be done. Often the navigator will be looking things up to help when things aren't working, or will be thinking about how things can be improved. The pair will switch back and forth between roles while they are pairing.

If the pair are using test driven development they might switch back and forth between each test they write. Otherwise they will find a suitable point, often when they decide to commit the code they've written.

There are several benefits to pairing in software development:

  • Increased code quality due to the extra pair of eyes
  • Increased code quality because you put in more thought if you are having to explain what you are doing as you go along
  • Getting new developers up to speed on a new code base
  • Reduces the 'bus factor' as more developers will have experience with a code base
  • Sharing and learning techniques
  • Increased code quality due to having to talk through different approaches instead of jumping straight in
  • Strengthens team cohesion rather than developers all working independently

There are some downsides:

  • It is surprisingly tiring for the developers involved. I find a whole day of pairing very tiring. Breaks should be encouraged.
  • There are some days where you just aren't up to it
  • Pairing with morning sickness is hell
  • It can be very person dependent - pairing with someone who doesn't communicate isn't enjoyable or productive
  • Similarly, pairing with someone who just wants to tell you what to write, or nitpicks in an unconstructive way is a fast way to destroy your confidence

If the pair never switches over, it is likely one of the pair is getting frustrated. This often happens when there is a big difference in experience between the developers. It can happen in either direction - sometimes the more senior developer will take the keyboard but then end up navigating as well and just working away on their own, leaving the more junior developer just watching someone code. It can also happen the other way, where the senior developer lets the junior one drive to give them experience, which after some time becomes exhausting, and stressful because you can feel you are just being watched. It is best to switch back and forth regularly.

How much should you care

Ultimately it is up to your developers, but it is a good practice to encourage, and a good sign that your developers are working well as a team if they are doing it.

Things you can do to help:

  • Don't require everyone to be working on their own card
  • Ask at standup if anyone wants to pair
  • Keep an eye out that the pairs are rotating - the same people shouldn't be always together
  • Make it clear that you support it and don't expect developers to just churn through cards as quickly as possible
  • Don't force it. Sometimes people really don't want to pair that day and that is ok.

See also

How to support pairing