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:
- Tasks that require a lot of research up front.
- Topics where one person doesn’t know the domain at all.
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:
- Tuple - high definition, low latency, you can draw on the screen, and typing on your partner’s screen is seamless.
- VSCode Live Share - Live share is a VSCode plugin that allows participants to join and see your VSCode session. They retain their editor settings, which is a neat feature. You can have people follow you, and they can type in your window. I would use this plugin with video conferencing, or even Tuple.
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.