Effective pair programming

5 facts about pairing that will change your experience

I’ve been pair programming for a number of years, but I’ve only recently got to the point where I can genuinely say that it’s more of a help than a hindrance. Previously, I either had the wrong attitude towards pairing, or I was following a format that didn’t work. Here are five facts about pair programming that helped me change my attitude.

1. It’s almost always “slower” than solo coding.

Slower is a very subjective term. You could be referring to anything from the utterly useless “number of lines of code per minute” to the more useful “time it takes to release a feature”. However, you should also consider the longer term: how many hours would you spend fixing bugs caused by a rush-job on a feature, which you coded alone late one evening?

It might feel slower when you’re in your pairing session, especially when your partner questions every single line of code you write. However, the reality is that two pairs of eyes are far better at catching bugs than one. Simple mistakes are often picked up straight away, rather than causing minutes (or hours) of confusion and frustration.

Also, it’s much easier to misunderstand a feature when coding alone, and to go off in completely the wrong direction. Talking a feature through with someone else will normally eliminate this danger.

Finally, you may think you have the perfect technical solution to a problem, only to discover, 3 hours down the line, that it doesn’t work at all. Your pairing buddy could have told you that straight away, and saved you the time.

Go into a pairing session with the expectation that it will feel as if it’s taking longer, but that you will emerge with a more solid and accurate implementation.

2. Pairing is fun. If it’s not fun, you’re doing it wrong.

When I started pairing, one of us would write both the tests and the code to make the tests pass. The other would watch, chipping in with advice and suggestions. This is extremely dull for the onlooker, and normally leads to sneaky, Twitter-based distractions.

The pairing sessions that I’ve enjoyed have followed this structure: pair #1 writes a failing test case, pair #2 writes the code to make that test pass. Keep it that simple, and try not to interrupt the test writer until they’ve finished writing their test case. As the tests are written, the details of the feature come out in the wash. Without wanting to sound too corny, it feels like a game, and makes pairing genuinely fun.

3. It’s intense, so take regular breaks.

Programmers are often bad at taking breaks on a regular basis, mostly due to the fact that writing code and solving problems is an addictive business. However, I don’t think anyone needs convincing of the physical and mental benefits of taking regular breaks. Many programmers can attest to the fact that solutions to difficult problems are often worked out when you’re away from the computer, and sometimes subconsciously.

I’ve found that pairing is even more intense than programming solo, as there’s the added element of interpersonal interaction and communication, which becomes exhausting. When you sit down to pair, set an alarm (or use some software, e.g. my own breaktime project) to take regular breaks. I’d suggest at least one 5-10 minute break every hour. It will also reduce your desire to murder your partner, which is a typical side effect of long pairing sessions.

4. You can always learn from your pairing partner.

It doesn’t matter who is senior, and it doesn’t matter how long you or your pair has been coding. Everyone has the ability to spot holes in logic, and to offer different approaches to solving a problem.

If you’re more senior, then you have to approach a pairing session with an open mind and an expectation to learn. Don’t expect to purely play the role of the teacher — look at the qualities that your pair has, and learn from them.

If you’re more junior, then you have to believe that you have something to offer to your pair — don’t dismiss yourself on the basis of experience, as experience can lead to single-mindedness or assumptions.

This leads nicely into my final fact…

5. Pairing is harmful to the ego.

When it comes to pairing, arrogance and pride are your enemies. It can be very humiliating when your pair spots the stupid mistake in your code, which you would have quietly removed when coding alone.

Be prepared to make mistakes, and to laugh about them. Create an environment where you can point out mistakes without pointing the finger at each other. If either of you are constantly on the defensive, it will be a very frustrating experience. The best way to enjoy pair programming is to leave your ego at the door.