Pair programming is an excellent boon to code quality. But in a remote work environment, how do you pair effectively when programmers are thousands of miles away from each other? After some very successful pair programming experiments during our work on a facial recognition-based beer tap project, we decided to create a remote pairing guide to help our developers be even more successful in helping our clients.
Remote work gives you more control over your schedule and the ability to work from anywhere. That does, however, come with the challenge of working with others with different schedules or time zones. It is important that you coordinate with your pair so that pairing can actually happen in the first place.
Before you start pairing with a new partner, share your timezone and your normal daily schedule. Some parts of your schedule may be set in stone. For the parts that aren't, consider making adjustments to accommodate your pair's schedule.
It's hard to focus when your pair is in an audibly or visually noisy environment. This effect is amplified when the noise is blasted through headphones into your ears. For this, and other reasons, Very has a video chat code of conduct for working with clients. Many of these rules also apply when working with each other, including:
- Working in a quiet space, away from commercial activity or noisy family members.
- Maintaining a clean and professional appearance — both personally and in your workspace — to minimize visual distractions.
- Making judicious use of mute features (like shush) to reduce background noise and to cut out sounds like typing on a keyboard, sneezing, chewing, etc...
- Turning the camera to make the interaction feel more like an in-person pairing session.
To be best practitioners of pair programming, Very expects our programmers to make use of high-quality equipment. While we do not universally mandate particular equipment, some of our suggestions include:
- A wireless headset with a mic such as the Logitech G533 or a desktop mic like the Blue Yeti with a headset.
- Reliable, high-speed Internet.
Very also has a suite of pairing tools that we recommend for consideration. What works best will depend both on the pairing style you're comfortable with as well as the languages and frameworks you're using.
There are several screen sharing and video chat options at our disposal, all of which need reliable Internet access.
- Slack - This is Very's core communication tool and features a readily available video chat and screen sharing feature with the ability to draw on the screen. This service can, however, be flakey at times.
- Zoom - Reliable streaming of high-quality video and voice. Zoom also has drawing tools, though you have to hunt for them.
- Google Hangouts - Only requires Chrome, which most people have access to. However, video and screen share quality is usually not that great.
Tips for Screen Sharing
- Keep your screen clear of distractions, including notifications and apps you're not actively using.
- Coordinate with your pair to make sure that the screen share is comfortable to view for both parties. (e.g. try to avoid sharing a 4k 30in display to someone who is only on a 15" laptop, or adjust resolution or text size for readability)
- Keep as many of the relevant windows viewable on the screen share.
- Coordinate with your pair to ensure that they can see enough of the code you're working on. (e.g. if you're on a 15in MacBook and your pair is on a large display, they might appreciate the editor window being half or full screen. This will help minimize needing to ask you to scroll around)
Other Sharing Options
Sometimes screen sharing isn't reliable, and you need to scale back to just voice chat. Other times you might want to share code editor control. In these cases, try one of these flexible, low-bandwidth options.
- tmate - Share your terminal with multiple panes and windows in the terminal.
- Very useful for those comfortable on the command line
- Can share live test logs, editors, repl, etc....
- For future consideration: Standardize the tmate config
- Atom + Teletype - This editor and plugin combo allows for sharing the currently open set of files from the host's computer.
- Each user gets to navigate and edit independently if they wish, or can follow another user around the codebase
- Does not currently share the whole source tree to viewers
- Only shares code, no terminal, server or other access
- Visual Studio Code + Live Share - Similar to Atom and Teletype, but a lot more powerful.
- Viewers get access to the whole source tree
- Can share terminal, debugger and even development servers to viewers
Multiple Monitors or Many Windows
You or your pair may have multiple monitors or may toggle between code, console, tests, the running app, etc... In these instances, there are too many windows to fit on a screen share. While it does take some additional setup, using the various sharing tools together can alleviate these issues while providing a powerful way to work.
For example, using Teletype or Live Share to share code editing, tmate to share console output, and a screen share to show the running app allows sharing more information all at once. This enables each programmer to select what to view independently. Consider talking to your pair about combining the use of an additional tool or two for a better pairing experience.
The Pairing Session
When starting a pairing session, it is often helpful to review the current story and make, or maintain, a task list for the pairing session.
Communication is one of the crucial skills for pairing remotely. Talk through the strategy you will be taking and talk about the how and why of the code that you're writing while you're writing it. If you're doing research, talk about your findings. Also, don't be afraid to break out a digital whiteboard to hash out ideas.
And of course, if you need to step away from your desk for a while, let your pair know how long you'll be away.
There are several ways to approaching the actual pairing itself. Each one lends itself to different levels of skill in the project's tech stack, the current situation at hand and personal preference. It is probably a good idea to change up who is filling each role in the strategies to keep both attention and minds fresh.
One person is focused on writing the code, while the other researches, plots a course, and keeps an eye on Slack for outside questions or notifications from project services.
Test Code/Production Code
One person writes the test code, and the other writes production code. This allows both developers to be engaged in the code and allows a little separation between tests and production code.
Jedi Master/Jedi Apprentice
Best used when there is a wide gap in experience between the pair and allows the less experienced of the two to gain knowledge rapidly. The apprentice writes the code while the master explains how the platform works, how to approach a problem and fields questions from the apprentice.
We at Very have found that with some thought and preparation pairing between programmers at opposite ends of the country can be just as effective as pair programming in person. The tools are continuously evolving, as are our methods and practices. As such, we expect our pair programming guide to continue to evolve.