There are a number of XP development practices that are considered controversial, and pair programming is one of them. I’ve written about pairing previously, and there are a lot of other great resources on the subject, including more than one amusing video on the challenges of pairing.

A lot of people give up on pairing before they ever really give it a chance. They’ve heard horror stories from other devs who apparently had a terrible time with it, and can give you 100 reasons why the practice simply won’t work for them. It seems that people either love or hate pairing, for a variety of reasons. For the ones that hate it they’ll tell you that there is simply too much pressure working right next to someone. They’ll tell you they had a terrible pair partner who had bad body odor. They’ll tell you that they can only work alone, and won’t even bother giving you a reason as to why they can’t be bothered to work next to someone else.

As for the devs who enjoy it and end up being very productive in this mode I’ve noticed a number of common behaviors that make pairing more effective, and these are what I’m going to talk about here.

Enabling Line Numbers

Grunt and point went out of style with the Neanderthal. A behavior I see in a lot of developers who are new to pairing is to see a potential issue and then to point and cry out something to the effect of “Ah, there is the problem right there!” Meanwhile, their pair partner is still scratching their head in confusion trying to figure out where the other developer is pointing on the screen (This is impossible to follow if you are pairing remotely!). One of the first things I do when I configure an IDE is to enable line numbers. This allows you have a much more accurate conversation with your pair partner. It now becomes “Ok, line 42 is the problem.”, and the other developer immediately knows what you’re talking about. They can go directly to line 42 without trying to follow your finger and your line of sight.

Give Up the Keyboard

I’ve developed a habit over the years when I’m pairing. Essentially, as soon as I see my pair partner reach for the controls I immediately lift mine off of the keyboard and mouse. This helps to prevent the awkward moments in pairing in which both devs are trying to drive at the same time. This is more than just a muscle memory reaction, it’s also a way of thought that you don’t always have to be in control. It’s the acknowledgement that someone else is allowed to have input as well.

Suggest, Don’t Dictate

Effective pairing is bringing two minds together to solve a problem. Both minds need to have an equal say in matters, which means agreement needs to be reached on what an appropriate solution looks like. This means one dev can’t simply shut the other down, as that can quickly lead to discontent and disengagement. This is the kind of behavior that leaves a bad taste in someone’s mouth for pairing.

Having said that I’ve recognized in myself to be aggressive when it comes time to develop a solution. I see a way forward and go for it. This doesn’t work in a pair; you have to be willing to hear what your partner is saying, and vice versa. Therefore, when you are part of a pair your tendency should be to suggest potential solutions rather than to dictate them. Leave the door open to discussion, and allow for the possibility that there might be a better solution waiting to be discovered by both involved parties.

Thinking Out Loud

Experienced pair partners all have at least one thing in common: they think out loud. They don’t keep their thoughts to themselves, because it leaves the other developer in the dark. Thinking out loud spreads the brainpower around. Some of the best pairing experiences I’ve had started when I’m talking my way through a problem, and my partner starts riffing on this and provides their own ideas. Pretty soon we’re working through the problem quickly, and before you know it we have a solution.

Developers new to pairing often have to learn to open up and “let their brain out” so to speak. They’re used to working in silence. After they’ve been pairing for a while though thinking out loud just becomes second nature. Good pairs communicate constantly. They’re discussing ideas, talking about the best way to fix a bug, figuring out a better design, or learning something new. There isn’t an effective way to pair and not think out loud.

Let Your Partner Finish Their Thought

While thinking out loud is definitely a good thing, so is letting your pair partner finish their thoughts. This applies to code as well and not just conversation. If your partner is currently driving and they’re in the middle of writing some code, let them finish instead of grabbing the keyboard and mouse away to fix what you consider a glaring error. After all, you want to be able to finish your thoughts without receiving an interrupt signal too, don’t you?

Pay Attention

It’s funny, one would think this goes without saying. After all, this is the dev’s job right? Surprisingly, a lot of devs new to pairing seem to tune out unless it is their turn at the keyboard. The pair will kick a build and out comes the phone. One dev will start driving and the other will very obviously not be paying attention. It stops being pairing at some point and just becomes two people who happen to be sitting together with one of them doing the work. For pairing to be effective both devs need to be fully engaged in the process. Both devs should be actively contributing to the code and to the conversation.

Acknowledge the Awesome in Someone Else

Another simple, should-be-obvious tip that is often overlooked. It’s easy to say “OK, we finished this piece of work, let’s grab the next one and move on”, when in reality what should be happening is saying “Hey, you really saved us a ton of time with that refactor, great job!”. We need to be willing to acknowledge when someone other than ourselves does something awesome. I’m not talking about giving empty praise, I’m talking about recognizing someone outside of our mind when they deserve it. Attitude matters a lot when you’re (living) pairing, and people appreciate a good attitude. Take time to take joy in your work, and in the work of others. If you’re not taking joy in what you and others do then why are you doing it?

Pairing at the individual level is not at all easy when you first get started. It is not exactly encouraged by the existing developer culture, though it is more accepted theses days than it used to be. Hopefully the points I’ve discussed will help to make your pairing experiences more enjoyable and effective. In my next entry in this series I’ll talk about pairing at the team level, and how to engage many pairs efficiently.