Effective Remote Pair Programming (Part 1)

Pair programming is a software development technique where two programmers work together at one workstation. It’s a great way to improve code quality, clear blockers, and share knowledge, and has been a tool we’ve used with great success at Merit. However, since we’re currently working from home, it’s become more difficult to use traditional pairing techniques and more important to consider why and how you’re actually pairing.

When pair programming remotely, ensure that you keep to the basic principles that make it work and have the effective tooling for your sessions.

Understand the purpose of the session

Pair programming sessions tend to fall in one of a few distinct categories. It’s important to understand which one you’re doing before you get started, and even more so to have a successful session when remote. I’m going to refer to these different types of pairing sessions as “troubleshooting,” “learning,” and “code quality.”

Troubleshooting

Troubleshooting sessions are when a developer (dev) needs help solving a specific problem and reaches out to another dev for help. This means you will have one thing to focus on and a clear understanding of when the session is complete. 

Learning

Learning sessions are when a dev who is less knowledgeable about some aspect of the project seeks general help from a dev who has more experience in that area to ensure that their work is of high quality and delivered on time. This doesn’t necessarily mean that the “teacher” is senior to the “learner,” just that the learner has some task they are uncomfortable working on alone. 

Code quality

Code quality sessions are when a pair of devs are working together to ensure that the final work product is of especially high quality. Having a separate set of eyes on mission-critical code as it’s being written can be incredibly valuable and help catch bugs as well as code smells before they make it far along. This is particularly beneficial when the architecture of a specific solution is new or not yet defined, or when the solution is highly technical in nature. 

Remember the Basics

It’s easy to make a pair programming session onerous or inefficient. Some simple rules can make pair programming, remote or otherwise, much more effective. 

Make sure you’re getting something out of it

Don’t pair unless at least one of the developers is getting something out of it. If you’re making a simple change that anyone on your team could handle trivially, it probably isn’t worth pairing to solve. If you’re refactoring or making broad architecture changes, however, having a second pair of eyes to validate that you’re making changes that everyone agrees will improve the codebase is invaluable.

Experiment

Do make an effort to experiment with alternative solutions while pairing. After coming up with a viable solution, take the time to explore alternatives. This could be as simple as asking questions like “could we extract that into a function?” or “could we do that without mutating data?” It could also be as complex as “is our database sufficiently normalized here?” or “can we restructure this to use sockets instead of polling?” Taking the time to explore these alternatives will help both of you settle on a solution that you can agree on. Either you will discover a better approach, or you will have more evidence to support your initial strategy.

Make sure you both write some code

Don’t monopolize the keyboard. A good pairing session should involve both parties writing code. This is true regardless of why you’re pairing. Writing code flexes different muscles than reading and commenting on code. If both parties trade off writing, then you’ll find higher quality code and better learning outcomes from pairing sessions.

Treat it as a discussion

While pair programming, both developers should be talking back and forth. If a pairing session feels more like a lecture, then it means something is wrong. 

If you find yourself the only one speaking, make sure that you are letting your partner get a word in. Try to avoid words like “obviously” or “definitely,” which don’t leave room for alternative approaches. Remember that one of the benefits of pairing is that your partner may have a different perspective, and discussing that disparate viewpoint could lead to better code and better developers. 

If you find yourself unable to keep up with the conversation, ask for clarification. Push back on statements you disagree with or don’t understand the rationale behind. You might be missing information that would help you understand the approach better, or discover that the other dev should be approaching the problem in a way that’s clearer.

If you find that both of you agree on everything right away, reconsider whether the problem you’re solving is one that’s worth pairing on. If the outcome of a pairing session is the solution that both of you would have initially agreed was obvious, then it’s unlikely that anyone got much out of it.

For more tips and details on how to use tools effectively at home, check out part 2 of Effective Remote Pair Programming.