8 Ways to Make Remote Pair Programming Awesome

What is Pair programming?

Pair programming might be a well-known agile development practice, but it remains sort of a mystery for many. And for those who are unsure of the practice, remote pair programming might seem even more challenging. But once you get the hang of it, pairing is so effective in improving code quality, making less errors, and helping you to always be learning. 

Pairing is a learned skill, only learned by practicing. I’d like to help everyone understand how beneficial pairing is, even though it doesn’t come naturally to everyone. So, take every opportunity you can to practice pairing, including utilizing remote pair programming.

8 basics that will make remote pair programming awesome for everyone involved:

1: Basic setup

For remote pair programming, you’ll need your basics in place. Strong wifi and a quiet environment is obviously important. But don’t overlook the other non-obvious basic elements:

Use a headset and a microphone, not your computer’s mic. Using a dedicated microphone just helps make sure all machine humming, fans, and other background noise is kept out of the communication.

Use video conferencing software. Being able to see each other’s faces when pairing – especially when remote pair programming – is important. It helps you pick up on cues for when to jump in and when to let your pair finish a line while in the zone.

But don’t rely on video conferencing for the actual process of pairing. Screen sharing, even if you’re able to draw on someone’s screen, is actually collaborating, not pairing.

Run Zoom or Slack for communication, but run one of these tools for the act of pair programming:

Wemux – Best if two people are VIM users.
Atom-pair – Snappy, but the person who starts the ‘portal’ will only see the changes tracked on the correct file.
Visual Studio Live Share – Just released at the time of writing this post, so be sure to share your thoughts if you’ve used it!
Teletype for Atom – This is similar to VS live share: both offer live collaboration on the same codebase. This was also recently announced, but is actually available to use, albeit in beta.

Don’t let tools stop you though. You can also set up a structure where one person drives for a period of time, pushes up changes to remote, and then you switch roles.

2: Water

You’re going to talk more than you would during any other coding session. So, stay hydrated. Take care of yourself. This is no place for martyrs.

Work-life alliance applies during work as well as outside of work.

Practice self care. A pairing session is a partnership between two human people so remind and allow each other to take care of your human needs, starting with, you know, water.

3: Breaks

Speaking of human needs, more water means more bio breaks. Agree upfront to take breaks.

Set a timer so that no one fears the interruption that ends up pushing you an hour past the agreed-upon break time. This is pair programming, not a marathon coding session.

Have a stretch, take a walk. Eat a meal or have a snack and come back to pairing. The exercise might jog out some other ways of looking at the task. And you’ll keep your mood from turning sour due to lack of blood sugar.

And, do a check-in with yourself and your pairing partner. If it’s just not working for you today, please, don’t force it. No one gets hurt when you take a moment to recharge. But, trying to force the issue and collaborate with someone, for potentially long periods of time, is definitely a recipe for failure.

Everyone is different and you know yourself the best. Know and practice the techniques that prepare you to bring your engaged and intentional mindset to your pairing session.

4: Arrive prepared

Pairing is a meeting. It’s important to reframe pair programming so that each participant is able to prepare for it appropriately. And you wouldn’t accept a meeting without first, making sure it’s necessary and second, being able to review the agenda, right?

So, first: is this meeting necessary?

Rubber duck with yourself, or in your team chat, to figure out if your problem can be resolved with other methods. More often than not, someone else on the world wide web has dealt with a similar issue and can help point you in the right direction. If that fails, well, now you’ve done a good chunk of the meeting prep. You should have answers to these questions before engaging your colleague so you can quickly tee up the meeting with context:

Clearly articulate the challenge to yourself, and then to your pair partner, before agreeing that yeah – the meeting is necessary.

And then, you’ll be able to frame up the pairing meeting with the agenda.

Your pair programming agenda should answer these questions:

• What will we work on?
• How long will we spend?
• When will we take breaks?
• Who will drive first?
• When will we switch driving and observing?
• What type of pairing meeting is this?

5: Types of pairing

Oh, I’m glad you asked. There are different reasons for remote pair programming. And you should always be specific with your pairee about what type of time and energy investment they are signing up for when you make the invitation.

A quick sync and alignment – for example, a developer and a designer look at an approach together. When you request a pairing meeting for this type of issue, you can set the expectation with the other person that this is a brief sync-up. “This is what I think I’m going to do to solve this problem and I’d like some feedback.”

There probably won’t be any actual coding in this pairing, but rather a demonstration of code and a full background on a problem.

Identify a specific block in a smaller piece of code – You’ve got something that’s a bit squirrelly, and you know someone who can help un-squirrel it so that you can get past the block. There will be coding performed during this pairing, but it will likely be solved in less than an hour.

A more complex lesson or story to work You’ll want to be specific when setting up pair programming for a complex issue. You’ll use this type of pairing when you want to learn something new and benefit from your partner’s experience. But for the most part, this type of pairing will probably be used when you have a high-scoring ticket to work.

This pairing is going to take several hours. So it’s important to consider everyone’s commitments and schedule accordingly. We all have work to do, but we also all really care about helping each other do our best work.

That’s why respect needs to be one of the most important ways to make remote pair programming awesome.

6: Respect

Respect is the underlying value that needs to be applied across all aspects of pairing. In a positive developer culture, pairing is always welcome. Remote pair programming should not be considered as a problem or a sacrifice that someone else is making.

That being said, respect for each other’s time and commitments must be exercised. Demonstrate this respect by carefully scheduling pairing and setting reasonable expectations for your pairing meeting.

Using intentional language is another way to show respect. Be thoughtful about the words that you choose when working together to learn, teach, and solve problems. For instance, “No, that’s not what I meant” can be better phrased by asking “Do you mind if I drive?”

This makes for an easier transition that also gets your point across.

Convey respect by listening more and using empathy to understand your partner’s preferred form of communication. We are all different. Some of us talk more than others. Some of us communicate better non-verbally. We all have our thing. Be respectful of each other and create a better environment for more productive questions.

Listening more becomes even more important in remote pairing, since you lose the body language and energy cues you get when co-located. So really, listen more and stop interrupting each other.

Remember that the goal of pairing is to solve a problem and maintain a productive vibe.

7: Think out loud

There’s a lot of thinking to be done when building code. But when you’re pairing, you’re solving a problem together, so say what you’re thinking. Silence happens when you’re not aware of what you’re doing. Share the calculations that are happening in your head.

Thinking out loud is extremely educational in this setting. It helps the other person understand the concept, the background, and the story. And it keeps the conversation going.

Talk more than you think you need to. Silence is really, really awkward when you are remote. If you’re afraid to talk or if you find it hard to communicate your ideas, an easy start is to just say exactly what you are doing in the code.

Part of the benefit of remote pair programming is just this – practicing your ability to understand and communicate your thoughts, even if it sounds like mumbo-jumbo in the beginning.

8: Focus

The physical disconnect when remote pair programming makes social media tangents all the more alluring. But instead of getting ping-ponged around by all the world’s distractions, use the solitude to your advantage. The goal is active engagement, so devote your attention to the task at hand.

I have a hard time understanding how a loud, busy open office is a good environment for focused work sessions. When remote pairing, we can control our distractions by removing them entirely.

Move to a physical location where a chatty coworker won’t be a factor.

Snooze your notifications on your phone and your desktop. Literally, turn your phone face-down so there’s no chance it will distract you.

Remote pair programming gets the job done.

At its core, pairing is another useful strategy to work with your peers and get shit done. Sometimes remote pair programming just doesn’t work out, but there are always strategies to make it better. The best way to know what works for you is to take more opportunities to pair with others, think about what works and what doesn’t work, and continue to refine this skill set.

---

Agile Communication Culture Productivity Remote Teams Software Engineer