Remote Pair Programming

What is Pair Programming?

Pair programming is the act of two developers collaboratively designing software and coding in real time. This can involve sitting together and using the same keyboard and screen, or being physically separated (remote) and using software to share an environment.

Why Pair Program?

As explained by Tuple:

• Teams tend to ship slower over time because they accumulate sub-par code that impedes their progress.
• A pair of programmers tends to produce better code than someone working alone.
• Teams that pair often will maintain a fast shipping speed longer.

Pairing gives us the opportunity to see how someone else works, the mental space to ask “why?”, the courage to try completely new things with a partner, and the opportunity to share what we've learned with a broader team. It can also be a lot of fun!

Recommended Tools

Pairing without being in the same room is easier when using dedicated software that's built to increase the fidelity of online communication. A generic screen sharing tool isn't enough on its own because it doesn't allow shared control, and there's too much friction involved in switching who is writing code.

If you're limited to free tools, I recommend using a combination of Visual Studio Code Live Share for collaboratively editing the same files and sharing localhost, and another app like Discord or Zoom for voice, video, and screen sharing. This setup involves some friction, but it's a great way to get started.

Unfortunately, as of 2022 there isn't a free tool as good as Live Share that can be outside of VS Code. Potential options are Duckly, Saros for Eclipse or IntelliJ, and tmux and ssh for vi or emacs.

If you're able to pay for a dedicated solution, Tuple, Pop, and Drovio are solid applications designed for pair programming, and they all include free trials. If you use IntelliJ, Code With Me is similar to Live Share and works quite well.

Style and Etiquette

Style

The Driver/Navigator style is a good way to get started with pair programming:

• The driver types the code and stays focused on the current task.
• The navigator thinks ahead, ponders edge cases, spots bugs, suggests refactorings, asks good questions, stays zoomed out. https://tuple.app/pair-programming-guide/styles

How often to switch drivers

A pair should decide how often to switch drivers based on what feels right.

One strategy is to "ride the peaks" - if someone is in the zone, they should keep driving until they start to pause and hesitate. The other person should then jump in. The switch can happen as often as every few minutes (2-10).

Another strategy is to schedule how much time each person will spend driving. The pomodoro technique can be adapted to this. For example: first person drives for 25 minutes, 5-minute break, second person drives for 25 minutes, repeat. Take a longer break after 2 repetitions.

What if you and your partner don't agree how to proceed?

Pairing involves continuous compromise and negotiation. In some situations, you may have to try the following:

• Go with one idea and see if it works out. If it doesn't, try the other idea.
• If that fails, bring in a third person who's respected by both people.

Scheduling

How do you decide when to pair? The most common advice is to rotate pairs frequently, even as often as every day. No one should mandate how often a developer will pair or with whom. Instead, individual developers should coordinate based on their needs and on the open tickets in their sprint.

Here are some best practices to consider adopting:

• During sprint planning, or before picking up a new ticket, find a member of your team who agrees to work on that ticket with you.
• For each day that you plan to pair, schedule an uninterrupted block of time in your calendar (ideally at least 2-3 hours). Cancel meetings if you can't find an open block of time.
• Don't pair with the same person for more than 3-5 consecutive days.
• If a task isn't done after 3-5 consecutive days of pairing, break up the pair and bring in someone else to contribute fresh ideas.
• If one person in a pair is absent, that shouldn't block the other person.
• Comment on what works well and what doesn't in your team's retrospective.

How to Pair Effectively

To learn more about the specifics, navigate to https://demirdelic.com/posts/remote-pair-programming#how-to-pair-effectively and click on the text "Click here to view the quotes."

Of course, the main way to get better at pairing is to practice it!

Resources

Many of the ideas here are based on the following links:

• Tuple's guide, which is broken up into easily digestible individual articles.
• Practical Pair Programming, a very short $10 eBook that describes the essentials.
• "I Have Pair Programmed for 27,000 Hours: Ask Me Anything!"

Image credit: Philippe Bourgau