The value of pair programming in a remote environment

Pairing can be particularly valuable in a remote-first organization. It can increase relatedness and helps spread knowledge faster.

Pair programming (aka pairing) can be a contentious topic among software engineers.

Some look down on it, wondering why they would need someone to help them do a job they think they can do on their own. Some dislike it because the social and interactive process takes away from their comfort. Some companies and managers just simply forbid it. They believe that pairing makes it harder to assess individual performance or just leads to lower productivity.

All those things can be true.

I personally love pair programming. I have enjoyed it as a software engineer and I love seeing software engineers on my teams pair. Pairing creates faster feedback loops in the development process, leading to fewer coding mistakes and lower cycle time, and overall better code quality. It increases resiliency by spreading knowledge and creating a shared context in a team. And it helps strengthen relationships between developers, improving team morale.

This article is about the benefits of pair programming and how they apply even more so in remote first environments.

Helping develop and strengthen relationships

Developing software can be hard, exhilarating, frustrating, and rewarding. Going through these emotions with someone makes you closer to them. You don’t get the same connection by just reviewing a PR or talking high-level about design.

The day-to-day of software engineers is filled with mini-breaks: when code is compiling, tests are running, etc. This is the time when people naturally connect on a more personal level. Because you stay connected for multiple hours, there are also more chances of “life getting in the way” (kids walk in, husband calls, baby needs to be held, contractor rings the door bell, etc.). These mini life events naturally lead to more personal connections.

I have found over and over that pairing is an effective way to deepen a relationship with an individual, both as a peer and as a manager.

I recently started to ask all the software engineers joining my group to pair for a few hours with at least 4 software engineers outside of their direct team. I contacted software engineers throughout the company first to ask them if they would be willing to pair with new engineers joining my group. If they were, I added them to a list of “engineers you can pair with”. Instructions to the new hires were simple: reach out to four engineers from this list and work with them on whatever they are working on for 2 hours. My goal was primarily for the new hires to create connections within the engineering department.

I was a bit nervous about existing engineers not wanting to pair with new engineers, feeling like they were wasting their time, etc. Three months in, the feedback has been overwhelmingly positive. New hires love the sense of connectedness that it gives them. Existing engineers enjoy meeting new colleagues, explaining what their team is working on in a hands-on way by working on a concrete ticket.

Providing exposure to new contexts

That last point is an additional benefit from pairing. New hires quickly created a good mental map of the department and of our architecture by pairing with engineers on other teams. Teams within a same department can tend to be isolated. Pairing creates bridges between teams. Developers understand more concretely what other teams are doing and the challenges they face. This helps create empathy across teams.

You could achieve some of the same benefits with meetings for engineers across teams (aka “donut” chats). I haven’t seen the same success with those. The focus on solving a problem gives a common goals that makes the meeting feel more productive to engineers than just talking about what their respective teams are doing.

Pairing to gain context is particularly effective for new hires because they have so much context to build, but in my experience longer tenure engineers can benefit similarly. It is surprising how many engineers with longer tenure can be isolated and have little understanding of the context beyond their team.

Sharing tips and tricks

Every software engineer learns and develops a set of “tips and tricks” over time (shortcuts, tools, plugins, etc.). Those can make their every day life as a developer much easier.

The same tips and tricks, a.k.a tribal knowledge, also apply specifically to each company. Seeing how a more experienced peer handles a common error, how they access the production or staging environment, how they run tests, or how they use different tools can all be very helpful.

The answer is often to document those in a “cheat sheet” or in some other form. This is great and should absolutely be done. Another common idea is to organize department wide talks where engineers share those tips and tricks. This also can be good, but many engineers are shy about presenting something to a department-wide venue. Pairing helps deliver an in-the-moment learning experience and is complementary to documentation and presentation.

Conclusion

Pair programming is not a new concept. Its benefits and shortcomings are well known and studied. In a remote environment, it can be particularly helpful to help strengthen interpersonal relationships and improve team morale, develop shared context across teams, and spread good practices and tribal knowledge.