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.