Remote Pairing Improves Collaboration

While it’s a familiar phrase, “two minds are better than one” gets at the heart of paired programming.

Two developers can deliver code faster and with fewer errors. Working as a team also requires a conversation that challenges engineers to continually learn from each other. In the shared space of GenUI’s offices, this collaboration happens via pairing stations. Our stations consist of one shared machine where each developer has a mouse and keyboard.

Yet how can we overcome common obstacles to efficiency when a pair works remotely? In his July 2019 Tech Talk, GenUI Senior Consulting Engineer Rob Brennan tackled the pros and cons of this method while sharing several of his best practices for remote pairing.

Possibilities Over Obstacles

This topic originated while I was thinking about possibilities for paired programming when using freely available functionality and Visual Studio (VS) Code, but it eventually led me to consider higher methods of collaboration. At GenUI, we have a variety of different scenarios to consider – they range from folks collaborating on code at pairing stations to people who pair with someone offsite at a client’s location.

Here, I hope to honestly address common frustrations with collaborating remotely and offer some solutions to these challenges. By confronting these issues, we can take the first step toward finding solutions that boost efficiency – even and especially while working across distances.

Common Ground: Identifying Challenges and Frustrations

Let’s start by calling out several issues that can be easy to overlook.

We need to keep problems of low bandwidth or restricted connections in mind. Some folks may be working onsite with a client where the firewalls are extremely locked down. That developer might not be able to participate and pair to the extent that they want. Other times, challenges involve troubleshooting international collaboration. And one that doesn’t come up as often is collaboration while traveling or when availability is limited: even on vacation, one half of a programming pair may want to jump in and offer a quick answer to a problem.

Despite these oft-overlooked issues, the one I worry most about is the idea that remote pairing is one-sided and ineffective. We’ve all dealt with choppy audio and video. It can happen on a variety of fronts and result from something as simple as a bad connection or a network being overloaded. This leads to an inequity in conversations that contributes to remote collaboration’s bad rap. Yet thinking about remote pairing this way is defeatist.

Instead, if you explore further, you see that most issues are not with the practice of remote pairing itself, but with the approaches to collaborating.

• Participating in a two or three-hour conversation isn’t the way to keep people engaged since coding isn’t the most exciting spectator sport.
• Issues with lag distract from understanding the problem at hand, which is the goal of a team approach to development (and what we want to optimize).
• Screen sharing is often a hassle. I’m sure you’ve experienced aggravating screen sharing sessions and I don’t know of anyone who has had a superb screen sharing experience.
• If like us, you have folks that are traveling or working offsite, it’s almost impossible to drop in and participate on a project and look at the code base being worked on.
• Problems with meeting logistics impede the sharing of ideas. Meetings are creatures whose DNA is built from the simple communication needs to be heard and be able to hear. Meetings that involve engineers, leadership, and people in administrative roles often result in lively dialogue that can get lost when microphones aren’t present; ambient noise can also be tricky.

… most issues are not with the practice of remote pairing itself, but with the approaches to collaborating.

You can go through the process of getting a project spun up and the repo cloned… all that preparatory work. But eventually, there can be just enough friction (due to any or all of the common blockers above) to prevent someone on the other side from being able to have any meaningful impact.

Another practical problem is trying to figure out who is engaged with a conversation and who is listening – especially if you are not in the room. Someone might be jumping into a meeting from offsite and, depending on something as simple as volume level, it may not be apparent if the room is listening or if the message is being received. Key parts of the conversation can get lost this way.

One last idea that’s important to consider is that it takes more energy to deal with remote pairing. Whether you’re trying to throw some headphones on or simply focus on a conversation, adding even small requirements into the process can end up being a bit taxing. It’s true that remote pairing, through certain traditional approaches, might take more energy and focus (especially in extended sessions). This, however, opens a door to opportunities.

Seeking Possible Solutions

Instead of stopping at frustration, I’m always interested to see what we can do to solve issues.

Slack

We leverage Slack for many of our communication-based solutions. The main benefit of using Slack is the ability to have quick conversations anywhere. One of the challenges is dealing with Slack calls that can be almost as intrusive, or more intrusive, than a regular phone call. This is especially true if you’re not expecting to have a call come through this medium. I recommend that, to prevent interruption, you schedule times for Slack calls in advance. I’m sure there are plenty of people that get terrific value out of this feature. Use it if it helps get the job done but consider eliminating the element of surprise.

Zoom

We also use Zoom for video conferencing. There are a lot of features for this particular platform that aren’t being utilized. For example, you can give people toll-free numbers to dial into meetings if they can’t access a computer or view the conference video. It also allows you to create a free account for as many meetings as you want that max out at around 45 minutes. This is ideal because I’ve found that with remote pairing somewhere between 38 and 45 minutes is a good window before both parties need a break. (Yes, I’m that obsessive about time tracking but such attention to detail boosts efficiency.)

Visual Studio

One of the coolest tools we have to work with is pairing through VS Code. I know for some that thinking about using Visual Studio might seem like a lot of work but, if you fall into this camp, I simply ask that you consider the possibilities.

When I work [with VS Code], all parties can see the server I’m on. It’s very useful when needing extra eyes on a project because you can see where people are at …

As a bonus, VS Code also offers an extension (currently in preview) that allows you to use audio with your Live Share sessions – effectively allowing you to hold open collaboration sessions along with voice calls.

Free Your Mind

To get started using VS Code, you only need to make sure that you have either a GitHub account or a Microsoft account.

Imagine a case where you have a project fired up on a pairing station and want someone to jump in. It’s a huge benefit when everyone in a session is using VS Code because it doesn’t mess with any of its participant’s workspace settings. Another one of the benefits of using live share is that the other person doesn’t have to configure their machine; they’re able to access the code and view locally running servers from anywhere.

When I work this way, all parties can see the server I’m on. It’s very useful when needing extra eyes on a project because you can see where people are at without requiring them to download and install the software. You can follow each participant. Let’s say I’m in a different file and curious to see what the person I’m working with is up to – I can see where they are going and what changes they might be making to the code.

This is a handy tool and I encourage you to explore server sharing in this context.

Shared Virtual Machines (VMs)

So what are some other solutions? Considering the goal of reducing common pairing issues, I find the idea of shared Virtual Machines (VMs) very cool.

The release notes for VS Code discuss optimizing it for a use case where one workspace is shared by multiple people who access a VM remotely. That’s more common because, in this case, the VM becomes part of the project artifacts; whatever is set up remains part of the repo rather than being something that exists on a given pairing workstation.

And not only do we get custom environments but we have our own machines that we can turn on and off as desired. Some fairly standard VMs, if running 24/7, often cost around $50 per month per VM.

It doesn’t make sense to leave a bunch of VMs hot if nobody is using them. Thinking about the projects we work on – let’s say concept apps – where we’re doing something on a client request and they want to know that the machine is locked down, it might not be sufficient to have the code on a pairing station. Yet access can be audited on a VM. We have better tracking on our end that shows you the shared secrets and exactly who is working with the code.

This approach also frees us up to consider different projects. Take data analytics, for example. Imagine a case where it’s on a VM and some cloud sensor units that, if they were running 24/7, would give you a bill of about $3200 per month. Yes, that’s a lot of processing power but, like any cloud resource, you won’t (more importantly, shouldn’t) leave it lit up and running all the time. The larger point here is that costs associated with VMs, and worries about those costs, can be mitigated through strategic consideration of usage.

What If I Told You …

In addition to the cool opportunities with pairing using VS Code, some projects let you run this code on the VM itself – specifically a project called code-server. It’s a basic yet beneficial setup because not only can you remote in from laptops or pairing stations, but you can feasibly connect through a smartphone or tablet as well.

There are guides to getting started using code-server, SSH, and your docker container. I also found a tutorial on running VS Code on Google Cloud: https://fireship.io/lessons/vscode-cloud-coder-tensorflow/. It offers a quick video to guide you through accessing VS Code in a web browser. Further good news is that current options exist and that other services are competing to solve this problem (e.g., Redcode just bought a startup with a shared coding environment that is probably a lot more agnostic than AWS).

Overall, it would make us much more nimble if we could pass a VM around and have multiple people connect to it while also pulling a copy and running it locally. I encourage you to dig into this topic further because we can have a lot of fun with it and, in doing so, utilize remote pairing to the benefit of our clients and their projects