The ongoing global COVID-19 pandemic has pushed the distributed model to the forefront, with remote work becoming the norm, even for teams that are usually co-located. This impacts everything, from an organization’s global footprint, to cultural aspects like prioritising communication, building autonomous teams, and valuing collaboration.
And, while video conferencing tools like Zoom, Cisco Webex and Microsoft Teams are always available for teams, the challenge lies in how to make the best use of them in the new way of working. In this article, I will focus on the best practices that we, at Thoughtworks, have pioneered for remote pair programming.
We start by carefully choosing our tool to ensure maximum effectiveness of a pairing session. The available options include Zoom Breakout Rooms, Visual Code Live Share, Tuple, among others. What’s key to remember, is that screen sharing alone is not the only criteria to be met; both developers also need to be able to control the keyboard and mouse for productive pairing.
I have found Visual Code Live Share to be extremely competent, especially with the following plug-ins -
I have also found Live Sync to be extremely responsive, even with low internet bandwidths. What I like best about this application is that both developers can enjoy their own IDE preferences - themes, shortcuts and navigation without disrupting the other. One can even share their terminal from VSCode with local ZSH settings. You can learn more about Live Share, here.
Make sure the chosen tool is collectively agreed upon by the team and approved by your organization. We’d also advise checking your chosen toolsets for security vulnerabilities, like needing to upload your code to remote repositories (akin to man-in-the-middle) which could put your (and client) data and code at risk. You can read more about the security features Live Share provides here.
Another trick for those with an iPad and Pencil is to couple the setup with the screen mirroring feature on Zoom and screen share for optimum interactivity. Here’s a video with more details.
You can choose between the ping pong and driver and navigator styles of pairing. My personal preference is the driver-navigator approach as it doesn’t require switching of controls from one person to another as ping-pong does.
Here are a few things I’d suggest you should make a habit of, when remote pairing -
You will find more details on this subject at MartinFowler.com. I’d definitely recommend a read!
And, while video conferencing tools like Zoom, Cisco Webex and Microsoft Teams are always available for teams, the challenge lies in how to make the best use of them in the new way of working. In this article, I will focus on the best practices that we, at Thoughtworks, have pioneered for remote pair programming.
Pairing set-up
It is just as important to have an effective pairing set-up remotely, as it is in the office. This includes a big monitor and a keyboard and mouse.We start by carefully choosing our tool to ensure maximum effectiveness of a pairing session. The available options include Zoom Breakout Rooms, Visual Code Live Share, Tuple, among others. What’s key to remember, is that screen sharing alone is not the only criteria to be met; both developers also need to be able to control the keyboard and mouse for productive pairing.
I have found Visual Code Live Share to be extremely competent, especially with the following plug-ins -
- Live Share Extension Pack by Microsoft
- Live Share Audio by Microsoft
- Live Share Chat by Microsoft
Pairing in progress
I have also found Live Sync to be extremely responsive, even with low internet bandwidths. What I like best about this application is that both developers can enjoy their own IDE preferences - themes, shortcuts and navigation without disrupting the other. One can even share their terminal from VSCode with local ZSH settings. You can learn more about Live Share, here.
Screengrab of a collaborating team
Make sure the chosen tool is collectively agreed upon by the team and approved by your organization. We’d also advise checking your chosen toolsets for security vulnerabilities, like needing to upload your code to remote repositories (akin to man-in-the-middle) which could put your (and client) data and code at risk. You can read more about the security features Live Share provides here.
Whiteboarding
While pairing, one could seek quick huddles with team members to make decisions. Whiteboarding is apt for such discussions. And, when in remote mode, you have your pick of visualization tools like Zoom Whiteboard, Microsoft OneNote, Google JamBoard or Google Drawing and Mural. Personally, I have found that the simplest tools are the most effective - Mac’s Note pad or Mind map are my go-to tools, both of which are great to capture points during discussions.Another trick for those with an iPad and Pencil is to couple the setup with the screen mirroring feature on Zoom and screen share for optimum interactivity. Here’s a video with more details.
Screen grab of a remote team’s whiteboarding session
Styles of pairing
You can choose between the ping pong and driver and navigator styles of pairing. My personal preference is the driver-navigator approach as it doesn’t require switching of controls from one person to another as ping-pong does. Here are a few things I’d suggest you should make a habit of, when remote pairing -
- Interact with your pair verbally. It could be a ‘Yes’ or a ‘Fine’, or ‘Perfect’ to make your presence and participation felt. Avoid ‘Ghost Mode’ in meetings.
- Avoid hogging control of the hardware when pairing. This is a very common occurrence when remote pairing particularly if your pair is a less experienced developer or new to the team.
A few more useful tips for remote pairing -
- Use wireless headsets. They allow you to talk and engage as comfortably and as naturally as possible.
- Remember to take breaks.
- Leverage the Pomodoro technique.
- While pairing using independent meeting ids. Publishing the pairing matrix with respective meeting ids will help people connect with each other at any time.
- For spike stories (like research, proof of concept), step into the individual mode for a short duration. Then, resume with pairing or a dev huddle if needed to share your thoughts before concluding stories.
- Calling for adhoc dev huddles is easy when the team is co-located. In a remote setup, predefine a time for dev huddles or have the mechanics sorted to call for a more impulsive dev huddle.
- In case of low bandwidth issues, I highly recommend using VS Code Live Share or Zoom without audio. Use your mobile phone for clearer audio which also saves bandwidth.
- In extreme cases such as a complete internet outage, it's best to agree on different tasks in separate codebases, for the same story. For instance, the frontend and API development can take place individually with periodic sync-ups at predefined time slots.
Anti-patterns to avoid when remote pairing -
- Jumping into pairing without putting in place a trial period with the tools and schedules - ironing out basic pairing-related logistical issues will make the process more collaborative than challenging.
- Opting for new shiny tools that are the trend - evaluate the value (or benefits) of the tool versus the effort needed for the change from the entire team.
Making decisions in silos without sharing feedback and having effective and timely interactions with the team - broadcast decisions made while pairing and leveraging information shared on chat groups like Slack, Teams.
You will find more details on this subject at MartinFowler.com. I’d definitely recommend a read!
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
