What it’s Like to Pair for a Year

The Set Up

Usually when I tell someone I pair full time, they want to know the physical logistics. Every desk we have at our office is an adjustable standing desk that’s wide enough to fit a computer and a monitor. There is a keyboard and mouse plugged into each and my pair and I will face the screens shoulder to shoulder when we work.

There is one mouse pointer and one keyboard cursor, but each mouse and keyboard can control them, respectively. This means I could drag left while my pair drags right and we’d “fight” for where the pointer moves. But this doesn’t usually happen because programming (pair or not) is more about figuring out what to type than it is about typing.

When it is time to type or move the mouse, one person is established as the driver and the other pair is the navigator. The navigator watches what the driver types and guides them on their direction. Sometimes the driver and navigator are formally established, but usually it’s very informal and the pairs toggle their modes multiple times for a single line of code.

Rotating

When a team only has two developers, they’ll be pairing with the same person every day. But when a team has more than one pair, the developers rotate every day to avoid siloing knowledge within each pair. The work doesn’t always wrap up perfectly at the end of the day, so one person stays working on what they were working on yesterday and the other person works on a story that’s new to them. This helps transfer knowledge throughout the team.

If you have an odd number of programmers on a team, this means one person will be soloing (as opposed to pairing) each day. We try to make this a different person each day so that the team knows what the solo-er worked on and vice versa. It’s better to have an even number of developers, but soloing occurs on all teams because people get sick, go on vacation, or have to visit the doctor.

These scheduling interruptions happen, but on a typical day we avoid them by having the pairs show up at the same time (for breakfast and standup), go to lunch at the same time, and leave at the same time. This maximizes the time the pairs are pairing.

Productivity

One of the best things about pair programming is you always feel productive. When I soloed, I had a lot of downtime where I wrapped something up faster than I expected and was waiting for the next thing to work on. When I pair, I never feel like I’m twiddling my thumbs. In fact, quite the opposite. Both my pair and I want to move on to the next item on our backlog. I don’t feel like checking my email or Facebook because doing so doesn’t just make me unproductive, it makes my pair unproductive too. That’s why I rarely ever do these things when pairing with a programmer and I’m always looking for the next thing to work on when I finish a feature.

Although I always feel productive soloing, it doesn’t always feel like I’m as productive as possible. There are times where I feel like I have an amazing idea and I wish I could just implement it without needing to communicate it. But that would be rude so I have to slow down and communicate my idea and get buy in. Sometimes, even in hindsight, it feels like it would be faster if I didn’t have to communicate my idea. But other times I communicate my idea and my pair replies with an even better idea or presents a problem I hadn’t thought of that I would have ran into 30 minutes in if I were soloing.

On Gaining and Depth of Knowledge

Pairs share context in a way that can’t be undersold. When I soloed, each part of the code base was like a fiefdom. I owned this code over here, but if this part broke over there, it was another person’s responsibility to fix it. That doesn’t happen when you pair: There is team ownership for the code you work in and everyone is expected to contribute to the same parts of the code base. If any part of it breaks, the team is responsible for fixing it. This limits the bus factor. Experts in particular parts still arise, but when those experts pair with others, their knowledge is spread.

I remember when I soloed, I had to interrupt people to gain their knowledge. That was always awkward to do because I felt like I was bothering them. But when you pair full time, you’re expected to communicate with your pair, so it’s socially appropriate to ask them about something they’re an expert in. As a result of this cultural difference, you gain a large breadth of knowledge when you pair on a project.

[W]hen you pair full time, you’re expected to communicate with your pair, so it’s socially appropriate to ask them about something they’re an expert in.

But, I feel like this comes at a cost of a depth of knowledge. Before I joined Pivotal Labs, I learned a ton about Maven and that knowledge is still paying off in the projects I work on today. Unfortunately, it’s hard for me to imagine gaining that depth of knowledge while pairing. This is the price you pay for always being productive. You feel like you’re wasting time if you slow down to read how a Maven plugin works if you don’t need it today. But sometimes that knowledge will pay off in the future in ways you can’t expect now.

When to Split

It’s very difficult to read as a pair. Everyone has a different style of reading technical writing. Some skim, some read every word, some jump around non-chronologically, etc. This means I may want to scroll before my pair does, or I feel this article is irrelevant but they think the answer we’re looking for is on the page. The best solution I’ve come up with is:

• Have two separate tabs of the article and we can both read it at our own pace. Whoever thinks they’ve found the solution we’re looking for first interrupts the reading and explains it to the other then we move on.
• Another solution I’ve used is to just split up the pair, move to separate machines, and read as much as we can in 15 minutes (or some other amount of time you agree on). We regroup when this window has elapsed to see if we need more time.

This ability to split is a huge advantage that a lot of people don’t consider (including those that pair regularly). When you solo, you have to stop what you’re doing when you get interrupted. But when you pair, one person can join a meeting while the other person keeps making progress.

Personalities

There are certain personalities that are not fun to pair with. There’s the type that neither navigates nor drives. When you ask a question or try to collaborate they say, “I don’t care”. There’s another type that is always navigating and driving. They reject any alternative solutions to their own. They make their pair a backseat passenger. I prefer to solo than pair with people acting this way. This is why forcing people to pair doesn’t always work. It can be demoralizing for both people if one side of the pair doesn’t want to work that way.

I enjoy pairing with people who over communicate. If they pause and think about something, they’ll tell you what they’re thinking about. But it is possible to communicate so much that the other person doesn’t get an opportunity to express their ideas. Mutual respect is key. If one person’s opinions are continuously shot down, they will turn into a person who is not fun to pair with.

I enjoy pairing with people who over communicate.

Communication

Pair programming is often tiring. You have to communicate all day and that isn’t easy. When you solo, you get to contemplate alone, but when you pair you have to think about how to articulate your ideas. That said, I think my most tiring days have been after soloing where it feels like I’m hitting my head against the wall on an issue I can’t make progress on. That also happens when pairing but you’ve got someone with whom you can share the burden and think of solutions.

I didn’t realize how much I really love pairing until I had to solo temporarily again. Soloing is surprisingly lonely once you’ve been pairing for a while. But, I don’t think pairing made soloing worse, it just made me realize how isolating soloing always was. When you solo, you’re on your own and every time you talk to someone else you’re worried that you might be interfering with their work instead of contributing to it. When you pair, you have someone to joke around with, to bounce ideas off of, and to keep you focused.