Effective Pair Programming

I started my career in 2005 in Bulgaria. At that time, sitting with headphones deep in “the zone” for days on end tackling gnarly problems was the norm.

Then came pair programming. It was advocated by eXtreme Programming (XP) and the agile community for its various benefits. I was sceptical at the start: “Why use two people’s time for something that one is perfectly capable of doing? Surely having two pairs of eyes on something can’t compensate for this?”

Since then I have changed three companies and multiple teams and had a fair chance to see pair programming delivering on its promises, but also saw it being annoying and inefficient.

Pair programming gone wrong — original at https://dilbert.com/

I wanted to uncover what makes pair programming work and what does not. For that, I gathered a set of good practices and some bad ones. I also organized an open space talk and discussion to share my thoughts and hear what other peoples ideas and concerns related to pair programming are.

So here is where I got

There are several fundamental prerequisites to get an effective pair programming session:

• The programmers should feel comfortable
• Both programmers should be involved
• It should be done at a sustainable pace

The programmers should feel comfortable

This is a point that sounds very trivial, and yet I see it overlooked so often. I find this vital — pair programming is hard mental work and we don’t want to add physical discomfort on top of that.

The good news is that it is easy to solve with a bit of discipline and preparation. Here are a few questions to ask ourselves before we start pair programming:

Is there space on the desk for both?

The first thing is to ensure there is space for both participants.

I have seen various bad patterns — a desk that is completely covered with books and cups; the host occupying all the space in the centre; backpacks and cases of drawers preventing access to the desk.

Having the host tidy up some space and shift a bit from the central position may be all that is needed.

Can both see what is going on?

It is great that we can work with multiple screens, but it can be impossible for the navigator to read code if they are far from the screen.

We can solve this by being mindful of which screen we are working on or just by using mirror monitors when pairing.

Can both of us have access to a mouse and a keyboard?

We want both parties to feel authorised to contribute and to have no physical barriers to switching places. That is why being able to use the keyboard and mouse by both is important. I have seen two patterns that obstruct access to the keyboard and mouse — short cables and super fancy keyboards and mice.

Fancy keyboards and mice are cool, as long as we have an easy way to switch on ones for pairing guests. Having USB ports at hand or just having a second keyboards-mice set for guests are some ways to solve the problem.

Both programmers should be involved

To get any benefits from pairing both the driver and the navigator should take part in the process.

“Wake me up when my turn comes”

All the previous points are prerequisites for that, but there are a few additional things to consider:

Are we sharing our thinking while writing?

If the driver types in silence and the navigator watches there is little we can get from the collaboration. It is important that the driver narrates their thinking and the navigator listens actively and contributes.

Is the driver aware if the navigator can follow when navigating code?

I have seen an anti-pattern where the driver quickly scrolls a long class or navigates from class to class in the IDE and the navigator is completely lost.

This is a responsibility of both — the driver should be aware if their navigator can follow and the navigator should indicate where they struggle to catch up.

Is there space to draw or write?

People have different ways of thinking about problems — some are good juggling with data in their heads, some need a visual representation of what is going on.

Having something at hand to draw helps different types of thinkers collaborate and putting thoughts on paper helps with making sure both parties are on the same page.

Is the working environment familiar to both?

I am working in a team where half the developers use Rider, the other half Visual Studio. We use different version control clients and command terminals. That is cool. It can help us learn new ways to do things. However, if we are solving a problem that is challenging enough I would rather not have to deal with an unfamiliar keymap on top.

That is why I find it useful to have some common set of tools for guests and be able to switch keymap quickly — e.g by assigning a hotkey for switching keymaps.

Are we sharing the driver seat?

I have often seen one of the developers drives all the time when pairing. Often that is the one who is more familiar with the codebase or the owner of the desk.

In any case, I consider this an antipattern. It is close to impossible to stay involved when never given the chance to drive. I also find that it is far more difficult for someone that is less knowledgeable of a task to stay focused and contribute from the navigator seat.

I find that the best way to solve this is to switch regularly. I have seen two techniques that work very well for this:

Pomodoro timing — I often use an online Pomodoro timer to switch at every 25 minutes. This also prompts the pair to take a break before each change.

The ping-pong game — One developer writes a red test, the other fixes it and writes another red test, then they change.

When to interrupt the driver?

Imagine the driver makes a typo and straight away the navigator interrupts to correct them. Interruptions like that are more distracting than helping. It is better to give the driver a chance to correct themselves e.g. agree to follow a “3-seconds rule”.

Sustainable pace

Pair programming is hard work. It is all the cognitive effort of solving intricate problems plus some more to communicate and coordinate with another person.

“I keep going…”

So it is important to take regular breaks and to stop for the day when you can’t keep going.

It is not always easy to remember to take a break when we are focused on an interesting problem, so a timing tool can come handy. I have had success using a Pomodoro timer to make sure we take 5 or 10 minutes to rest every 25 minutes when pairing.

In Conclusion

Pair programming is a powerful technique, but to deliver benefits it needs to be done right.

Two people solving a problem together sounds like a simple concept but it is not so straightforward to do well, and it takes practice, patience and can benefit from employing proven tools and techniques.

Here are my golden rules for a good pair programming session:

1. Make sure you are both comfortable
2. Actively communicate
3. Take frequent breaks