Software

Remote Pair Programming During the COVID-19 Pandemic

How can remote pair programming be implemented during the COVID-19 pandemic, when all employees are working remotely? Our experience so far shows that it works very well!

We’ll show you what options are available, how we can use them, what works, and what doesn’t.

What has changed?

Employees are changing their work habits based on company guidelines or personal circumstances, so that, for example,

they work from home (ranging from full-time to part-time to not at all)
working hours are reduced (ranging from 0% short-time work to part-time arrangements under short-time work to normal working hours as before)
the technical setup is less than ideal (no laptop at home, no external monitor, no home office, no headset)

These changes present a number of technical and organizational challenges that teams working together must face today.

Understanding Pair Programming

Pair programming is a method in which two software developers work together on a piece of code at the same workstation.

„Write all production programs with two people sitting at one machine.“
Kent Beck

But pair programming is more than that. Adoption of pair programming remains low. One reason for this is that the classic “Driver and Navigator” style prescribes the following division of roles:

The Driver uses the keyboard and mouse to write the code. The driver’s focus is on pursuing and accomplishing a small goal. Distractions from other problems should be avoided. As they work, the driver comments on their approach.

The navigator observes the situation. They review the driver’s results as they are being produced and offer tips and suggestions for improvement. The navigator looks at the bigger problems in the code and keeps an eye on the broader roadmap.

The advantages are:

You’ll encounter fewer bugsYour motivation increases through close collaboration
You’ll write less code, which leads to lower complexity
Your communication within the team improves
Your integration into the team improves
You’ll benefit from others’ knowledge through intensive exchange

Despite its clear advantages, pair programming has a bad reputation. Adoption often stalls: teams try it out, it doesn’t work right away, and then they give up on it. Our observations align with this. Pair programming realizes its full potential over the long term and is not a short-term solution to problems.

The Remote Pair Programming Setup

Implementing pair programming can be difficult—or even fail—due to a lack of buy-in. All it takes is a few skeptical voices on the team. But what if we use this time of the pandemic as an opportunity to implement things that didn’t seem possible before?

Finding Available Times

One of the biggest challenges for pair programming is the greater asynchrony of many workflows. Pair programming requires synchronous time, since problem-solving, brainstorming, development, and testing all happen simultaneously.

In other words: I can devote myself to a 3-hour problem over the course of 3 weeks (bit by bit) or be in the flow for 3 hours and solve the problem. Often, the second option is the more efficient one, but it also requires predominantly synchronous, team-based work.

And that is precisely one of the biggest challenges. Due to the greater individuality, it has become harder to find synchronous time slots. But they are absolutely necessary just to get started.

Tools that help here include the calendar or tools like Doodle, especially when working with companies that don’t have access to your calendar.

Technology: Simple software tools

Due to the wide variety of options, the choice of tool often has to settle on the lowest common denominator.

Generally speaking, any screen-sharing tool that allows you to share your screen with others—and, if necessary, switch roles—can be used. Tools we’ve already used include:

TeamViewer
Skype
Microsoft Teams
Google Meet

In our projects, we’re currently making greater use of Microsoft Teams. Just like Google Meet, it offers a very low barrier to entry (compatibility with all devices, collaboration possible both within and outside the company, and ease of use). It also offers an automatic recording feature, which makes it very easy to record longer sessions and make them available to participants. These videos are automatically transcribed, so you can search the text for interesting points that need to be reviewed later.

Technology: Advanced tools

Tools such as Microsoft Visual Studio Live Share also offer integrated solutions that allow code, video, and audio to be combined within a single interface. This makes it possible to implement pair programming without compromise. This results in the following benefits:

Real-time collaborative work on code
Direct editing of code is possible
Easy switching between the driver and navigator roles
Customized setup is preserved, even during the sharing process

Since there’s no need to agree on a single environment and everyone can keep their own settings and shortcuts, it can be easier to get started working on the code itself.

Technology: Simple Software Tools

In addition to the software, there are a few basics without which remote pair programming would be virtually impossible. First and foremost, this includes a stable internet connection on both ends to ensure that smooth communication and screen sharing are possible.

Since communication is a crucial factor in pair programming, wearing a headset is beneficial. It should be worn close to the mouth to avoid distracting background noise and ensure good audio quality.

It’s also a good idea to use a second monitor so that both programmers can keep an eye on the shared screen while also having the second monitor available for chat or additional research.

The Limits of Remote Pair Programming

With a good setup, pair programming sessions can work well as remote sessions. However, there are limitations, as the personal interaction and direct face-to-face communication are largely absent. Nonverbal communication is also not possible—or only possible to a limited extent via video calls. This requires a special degree of empathy.

With a simple setup, additional problems can arise. If it’s not possible to switch between the driver and navigator roles, one of the participants can quickly be pushed into the role of a passive observer, while the driver moves too far ahead. This contradicts the very purpose of pair programming and should be avoided.

Exchanging code snippets can also be problematic with simple tools. The navigator must then explain their code ideas in words clearly enough for the driver to implement them. This is cumbersome and can be frustrating for both parties.

Simple screen-sharing tools also create potential for conflict, as participants must agree on a setup.

Conclusion

Pair programming can offer many benefits if you take enough time to implement it properly. Choosing the right tools is key, but you must take individual needs into account and cannot expect a one-size-fits-all solution (depending on the context and company). Pair programming is possible even with simple software tools, but compromises cannot be ruled out.

There are also many factors that influence collaboration: hardware, software, personal relationships, etc. It’s essential to be attuned to one another and to foster feedback-oriented, constructive communication.