How to Effectively Pair Program

#career

For me, pair programming is the best way to solve complex problems. I’ve had my fair share of poor pairing sessions. Ones where I was zoning out, or falling asleep, and that left me drained at the end of the session. But I’ve also felt the power of a good pair programming session. I could bounce ideas back and forth with my partner. I felt confident about the feature we released. And I learnt something new. Pairing leads to safer code, and reduces the knowledge silos on a team. The positives outweigh the negatives.

Pairing might not be for everyone, but I wanted to share some tips that have helped me in my pairing sessions. Hopefully, it’ll help make your next pairing session more pleasant.

Come with a topic to pair on - the problem matters

It’s important to have the right topic when pairing. Here’s what you shouldn’t pair on:

Pairing sessions where both participants are reading documentation is no fun. It’s much better to have read documentation beforehand and come with ideas. And if one of the participants doesn’t know the domain at all, it’s much better to spend that time context sharing. When pairing, you want both participants contributing to the conversation.

Everything else is fair game.

Know when to stop

Both participants should discuss when to stop or to take breaks ahead of time. They don’t need to be set in stone. If it’s a complex issue, I’d suggest taking the entire day to pair. The agreed times can change throughout the session. Maybe at the start, you take breaks every one or one and a half hours. But then later, you take breaks for longer and more frequently.

Use the right tools

This point is specifically about remote pairing. Find a tool that lets you interact with your partners screen. Both with a pointer, and also the ability to type. It’s a much better pairing experience when you can jump in to type out a missing command. Instead of saying it aloud or sending it over in a message. Here are my favourite tools:

Don’t get locked into the driver & navigator dynamic

There’s a “best practice” when pairing to define two roles clearly: a driver and a navigator. The driver is doing all the typing. While the navigator is offering suggestions, catching errors, and guiding the driver. Participants each get a turn driving and navigating.

In my experience, these roles aren’t so clearly defined. As a driver, you’re still navigating. And as a navigator, you could step in to drive at any point. The point is to make pairing interactive and engaging. You want there to be a feedback loop for both participants. Don’t get hung up on who’s driving and who’s navigating. Make sure both participants get a chance to type.

Check in at the end of the session

At the end of pairing, check in with your partner. How did they feel about the session? What did we learn? What should we do next? It doesn’t need to be super formal, just a conversation. But it closes the loop and sets you up for future pairing sessions.

Want to stay connected?

Subscribe to my newsletter

Weekly, bite-sized, practical tips and insights that have meaningfully improved how I code, design, and write.

No spam. Unsubscribe anytime.