Thoughts on pairing

Pair programming can be hard. It can be daunting at first to work side by side with someone for 8 hours every day, talking about almost every decision you make as you work. However, I really think the benefits far outweigh any downsides. You'll learn more, work faster, and likely produce the best code you ever have. You'll be better for it, the team will be better for it, and the client will get a better product because of it.

Before I get into it, first a little disclaimer. The company I'm working for does pair programming full time. Every project for every client is done in pairs. I've also only been at the company for a couple weeks, so I'm still learning all this myself. However, I think that puts me in a great position to compare pairing to non-pairing since I have both fresh in my mind (and is also why I started this blog in the first place).

Really, pairing is all about finding your rhythm. Once you hit your groove, pairing doesn't seem to be as much work as it might at first. After about two weeks it started to feel really natural for me, and so far I definitely prefer it to working alone.

Here are a few techniques I've picked up so far to make it a little easier to do:

First is the setup. Each member of the pair should have their own keyboard and mouse plugged into the computer. This allows either person to immediately take control from their seat and help out. It also lets people use the hardware they like, cuts down on germs, and basically lets pairing work really smoothly. I really can't emphasize this part enough, I think that each person having their own keyboard/mouse combo is truly essential to being able to pair repeatedly day after day.

Next is a technique called ping-pong. This technique works especially well with TDD. Say, for example, I'm pairing with Joe. I'll write the first unit test and make sure it fails for the right reasons. Then, Joe will implement whatever is needed to make the test pass. He will then write the next test and I will make it pass. Doing this, you ensure that both people in the pair get some keyboard time for both the tests and code, and, more importantly, it makes sure that both people in the pair understand each feature that is being added.

Much less formal than ping-pong, but even more important: don't be the victim of a keyboard controller! In each pair, inevitably there will be one personality that is more controlling than the other. Maybe one person is more familiar with the language or the framework being used, or maybe they just really like typing. The important part is to make sure that you are trading off who is driving regularly.

I would say 5 minutes is about the longest you want one person to be at the wheel, and ideally even shorter than that. One of the big benefits of pair programming is the knowledge transfer that goes on, and even if someone is slower at first, it's worth making the investment in them to help them become more productive.

Ping-pong also helps combat the keyboard-controller, so if you're having problems either being one or getting pushed around by one, try implementing a formal ping-pong coding style.

Another thing about pair programming that might not seem intuitive at first, is do everything as a pair! If you have a question about something and need to go talk to someone, go together. If someone else needs to ask you a question about a feature, answer it together. Remember, programmers aren't limited by their typing speed. Any seemingly lost productivity by having 2 people involved in discussions will be quickly made up by having 2 knowledgeable people working on the project.

TLDR; Pairing can be hard, especially at first. But if you stick with it and find your rhythm, it is definitely worth the investment.