Be a better navigator

Have you ever noticed how tiring a full day of pair programming can be? It's bloody exhausting.

I used to pair for 7-8 hours a day with a guy called Nigel. Almost without fail, we'd both be absolutely knackered by 4.15 in the afternoon, at which point we'd crack out the tea and biscuits. We needed half an hour in the comfy chairs to recuperate.

Here's a picture of Nige, doing just that (though I'm not sure what he's done with the biscuits).

This wasn't slacking; our brains needed a rest. Why is pairing so much more tiring than working alone? Constant communication requires non stop concentration.

Pairing with Nige was a lot of fun, but we were working so hard that we had to find ways to reduce the mental overhead. We had to communicate more efficiently. Along the way we picked up the following tips for the "navigator" (the one who is observing, rather than driving).

Pick your moment

Imagine that you're working on a problem, and that you're driving. You're just in the middle of getting a tricky bit of code working, when your partner says "Oh! I've just spotted a bug in the foozle method we wrote yesterday... there's an off by one error in the outer most loop!"

It's no doubt a great spot, but do you need to hear that right now? No. The distraction has put you off your stride and -- worse still -- you've had to try and think about two things at once just to listen to (and understand) what they said. That's an overhead that you shouldn't have to deal with while working on a hard problem.

What your navigator could have done instead is quietly made a note on a list (we called this list "the stack") that we maintained whilst working on a story. All you need is a piece of scrap paper or an index card. Writing these things down guarantees the navigator won't forgot them as soon as they get distracted by whatever the driver does next...

So it's not what you say, it's when you say it.

Now imagine the roles are reversed, and that your partner has started driving. They've just missed out an important bracket, but have kept on typing...

Did they notice their mistake? It can be a bit frustrating to have somebody pointing out errors that you're about to go back and correct.

I do my best to give them a chance to correct the error themselves before I point it out. And listening while we're typing isn't easy; the extra communication can really add up over the course of a working day.

So I try to:

• Keep an eye out for how my partner usually deals with obvious errors. Do they stop and fix them right away, or do they continue typing and clean up afterwards?
• Make sure that I don't say anything until I'm confident they missed it (at which point my comment is likely to be helpful).

If in doubt, ask your partner how they'd like you to approach it these things. They'll appreciate the consideration, and might feel more comfortable raising other questions about how you can work well together.

Reduce the bandwidth

So you've decided it's the right time to communicate something. What are your options?

I prefer the simplest way possible.

• If two words will suffice, don't utter a full sentence. Listening requires concentration, and keeping it brief makes it less likely that you'll break the driver's flow.
• If the error is obvious, don't speak at all. Just point. Or if you think it'll help, you could say something like "bracket" while pointing at the right location.

Pointing at characters on screen is easier with the tip of a pen than your finger. And I'm usually ready with a pen in case I need to add something to the story's todo list.

Being a good navigator involves being a good communicator, which isn't necessarily the same as being a good talker!