gears
within
gears

I figured I’d throw my hat into the ring and talk a little bit about how I pair, and what I’ve learned about it.

My first introduction to pair programming actually came in my freshman year of college: our professor required everyone to pair up on all homework assignments, and to keep that pair through the entire course. Me, I hated it. Neither of us knew anything and we ended up working at cross purposes. One of us would end up doing the work the other didn’t understand. By the end of the semester, we wanted to strangle each other. Pairing was a chore rather than a boon. I had much the same experience several years later, in another course taught by the same professor.

I’ve seen a huge difference between pairing in college and pairing out of it. Here are some things that would have made a tremendous difference to my pairing experience in college:

• Design your work environment for pairing. It’s hard to get a rhythm going with two people huddled around a small laptop screen. Open workspaces, mirrored monitors and keyboards, and ready access to coffee and snacks all promote a nice pairing environment.
• Set ground rules. I happen to think that certain ground rules, like keeping laptops closed while pairing, make a tremendous difference. When your laptop screen is open you (or at least I) tend to get distracted by other things, like incoming IMs and email. These don’t suck up a huge amount of time but the pair suffers from the overhead of the distraction, and it’s easy to lose your focus. If you need to pull up API docs, do it on the main screen.
• Maintain core hours and stick to them. It’s important that the entire team be present and focused at least some of the time.

These are things that you’ve probably seen before; they’re team-level recommendations, and TW does a pretty good job of sticking to them. Here are some more specific practices that have helped me on the individual level:

• Ping-pong. Just knowing that it was possible to set up a rhythm made a tremendous difference in my approach and productivity.
• Communicate. I love it when my pair stops me to correct my mistakes, because I find the bug that much more quickly. It also makes the coding process feel more collaborative to me. Some people hate it, though, and I tend to irritate the dickens out of those people, since it’s what I do by default. But I’m not trying to be a smug jerk, and would be happy to stop if you just let me know it bugs you.
• Rotate. You’ll get sick of anyone eventually if you spend too much time with them. Switch it up. If switching is painful, do it more often; it’s evidence that not everyone understands the codebase as well as they should.
• Come prepared. You’ll be a more effective pair if you’ve taken some time out before you join the team to understand the domain and the technology. No one expects you to be an expert, but if you’re familiar with the fundamentals it makes the whole process smoother.
• Put the brakes on occasionally. Don’t be afraid to hold up story work to check docs, root out bugs, or just ask your pair to explain something. We don’t pair because we think it grants us raw development speed; we do it because it produces better code and a better team, which will get software out the door more quickly in the long run.
• Time-box your discussions. If you can’t agree on something, flip a coin or ask another pair for their opinion. Remember that most decisions aren’t final. Agree to try something that you don’t like and then take some time later to re-assess that decision once the implications of it have been played out (and tempers have cooled).
• Finally, take breaks. Take a walk. Grab some coffee. Eat lunch with someone other than your pair. Do some coding outside your pair to try out new ideas or dive down into a part of your codebase you don’t understand.

Good luck!