Remote Pair Programming

Getting Started

You should agree on the objective of your pairing session at the outset. If one of you thinks the goal is to fix bugs as fast as possible and the other thinks it’s to learn Python, you might both be disappointed by the lack of progress you make in either direction. In many pairing sessions, the goal is simply to complete stories quickly and elegantly, but there may be some secondary goals you want to talk about. Perhaps you want to also get better at test-driven development or to clean up some smelly code as you go. Once you have these objectives in mind, take a moment to mention them as you’re starting and ask if your partner agrees.

If you’re growing into the pairing relationship, reflecting on the pairing process is important. Do you type noticeably more (or less) than your partner, and do they mind the discrepancy? If you’re pairing remotely, are you able to hear them clearly enough to communicate, or are they drowned out by background noises?

When you feel comfortable in your pairing environment, check in with your partner rather than assume that your feelings are shared.

The privilege of having more experience can shut down valuable lines of inquiry and stifle innovation with old habits, so make sure you’re deferring to a person with less power or status, even if you have to literally sit on your hands. Give them more time driving and make sure you’re using interrogatives, not imperatives. Far better to allow yourselves to explore the wrong path together than to split up in frustration and head off through the wilderness in different directions.

Being a Better Partner

There should be a dialogue running almost continuously. The driver (the one controlling the keyboard at the moment) is constantly thinking out loud in a practice called “reflective articulation,” which helps the navigator (the one not typing) understand what they’re doing and keep up with what’s going on. The navigator should be acknowledging the driver’s narrative, filling in the gaps, questioning their choices, noting potential problems, helping remember what that thing over there was called, and helping direct where to go next.

Good questions are open-ended, asked with genuine curiosity, and non-judgmental.

• Inquire about their reasoning.
• Consider alternatives.
• Be open to experiments.

An important job when you’re the navigator is to provide a “subliminal process check” and speak up when you think you’re working too long, trying too hard, or going too far on a task. Try questions like, “Is this something we should spend more energy on, or is it good enough? Is there something else could we be doing that’s more valuable?” Weighing the value of what you’re working on versus the effort required should always be in the back of your mind.

Wherever you are on the software engineering growth curve, you’re probably the best person to teach the knowledge you recently acquired to the folks just behind you. It’s a gift for you as well, because by articulating the thinking, circumstances, or history behind why things are done a certain way, you’ll get an even better grasp yourself on the principles you’ve already learned.

Each member of the team needs to be open to giving and receiving critical feedback. Being a good pairing partner means staying engaged, wrestling with interpersonal challenges, and not checking out and walking away when you experience adversity.

Soften the criticism by asking permission first. “Can I offer some feedback?” you might ask. “Can I bring up something I noticed?”

Frame it as an observation. “So I noticed we’ve been leaving a lot of comments about what the code does. I wonder, is that something we should be doing?” (Even if you’re sure it isn’t, make sure you ask sincerely.)

Emphasize what you would improve, not what went wrong. “Next time, I would like to spend more time driving, because I need to get a better feel for where things are in the codebase.” Or perhaps, “Next time we should try ping pong pairing, so we each have equal time driving. Would you be open to that?”

After a pairing session, conduct a nano-retro to quickly evaluate it and make improvements. On the count of three, each person scores the session on their fingers from zero to five. Take turns sharing what improvements would have made you give it a five and record the improvement ideas for the next time you pair together.

Conclusion

Like any powerful tool, it matters who wields it and how it’s used. Pairing can join people together and make new technologists feel like they have a place in the programming world, and it can also exaggerate power differences and make a person feel like even more of an outsider. Be mindful of the power you have and of those who come to the pairing table with a history of having their contributions ignored and devalued. Be sure to keep a running dialogue, give up control easily, be open to feedback, and reflect honestly on what’s working well and what’s not.