Pair Up

Monday 11 February 2013 at 12:24 GMT

This post is a result of a long discussion on the London Java Community mailing list on the value of pair programming. After explaining my own feelings and reading the opinions of everyone else, I wanted to get my thoughts down on paper (that's right, online, virtual paper) so I could be sure they actually make sense.

Here we go.

I find pair programming useful in a few different contexts. It's a great technique for learning quickly or teaching someone else, on a large scale, such as learning a new language, or on a small one, such as introducing someone to a class or module they've never seen before. Having someone right next to you who can answer all your questions is tremendously valuable, and saves a lot of time in the learning process.

It's also useful when working on a challenging problem, or one that's easy to mess up. Having someone check your work as you write it can be invaluable. I can personally attest to a number of catastrophic bugs that were caught early in the process by my pairing partner, as well as a few that slipped through because I was going solo and I didn't think about the problem hard enough. The methodical approach that tends to accompany pairing, as well as the debate, will push you towards cleaner solutions that avoid some of the pitfalls you see in everyday code.

Finally, it's exceptionally useful when starting to work on a feature you don't really understand. The key here is to find someone who understands the problem, not the solution. Quite often, it's far more useful to pair with a non-programmer, such as a tester, product manager or salesperson, as they're far closer to the problem and what the potential solutions might be. I've personally managed to cut out a lot of development work by pairing with the feature owner and asking the right questions about why we're building this in the first place.

All that said, I don't believe it's the way we should approach every single task. For some, it's not necessary. In others, it might actually inhibit the thought process. Some tasks are low-bandwidth but take a long time, leading us to take on a few and switch between them rapidly. If you think one human is bad at switching context, just wait until you see two try to do it simultaneously. Personal style and approach also matter a lot. As someone who likes to dive in and fuck up, I tend to say "yes" to pairing, as it's incredibly useful to have someone making sure I don't rush and still do things well. If you like to think a lot before writing a single line, you probably lean towards "no" most of the time, as the constant talking that comes with good pairing might actually get in your way and trip you up.

A large part of pair programming is your interaction with your partner. It's important to pick someone with whom you work well. This has nothing to do with whether you both like Star Trek or prefer vim over emacs (or tabs over spaces, C-style braces over Java-style, etc.). It's purely about your ability to have a reasonable conversation about the work you're doing in order to progress. If you hate emacs, you should be working with someone who loves it more often, not less. You should be encouraging your pair to write tests first, and asking them why this time is special and doesn't need them. You should definitely be getting into arguments, which is why it's so important to be able to work well with your pair: you should be focusing on solving the problem in front of you, not backing into a corner, clutching your precious ideas, because you feel threatened by him or her. The goal of pair programming, after all, is to do a better job than you would be doing solo. If you're not debating things, it's a complete waste of time.

Pairing is a skill. It's not something that I would encourage you to try once and then decide upon for life. You'll never learn how to play the piano with that attitude either. There's a lot you need to learn: how to let go of the keyboard (and how to ask for it back), when to prompt your partner and when to keep quiet, what you should be debating at any given moment, where your partner's weaknesses and strengths are and how to work effectively with them, and even when and how to point out that you need more coffee and a quick walk outside. It enhances your abilities to communicate, critique, debate, and think before diving in. I think it's one hell of a valuable skill to learn, and I'd absolutely recommend, if you're not already, grabbing a colleague and pairing on a problem today.