Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Experiences from Doing Remote Pairing

Experiences from Doing Remote Pairing


Doing pair programming when working remote helps to increase interaction between developers and build relationships in teams, it makes knowledge flow and can prevent developers from drifting away. You can experiment with tooling to find a setup that works for you to pair remotely. Pairing can be exhausting and slower, there are things that you rather do solo instead of working in a pair. Empathy and egolessness can emerge organically when doing pairing in a distributed team.

Why would you do pair programming when working remote? Jake McCrary mentions several benefits in his blog post on remote pairing:

The usual pair programming benefits apply to remote pairing; more people know the code, quality is higher, and it provides an opportunity for mentorship. Another benefit, more beneficial in a remote setting, is that it increases social interaction.

The most common response I receive when I tell someone I work from my apartment is "I’d miss the interaction with co-workers." When you work remote you do miss out on the usual in office interaction. Pair programming helps replace some of this. It helps you build and maintain relationships with your remote colleagues.

In the blog post making remote work Nickolas Means describes some additional benefits of pairing in a company where everybody is working remote:

One of the arguments for colocated work environments is that it makes it easier for knowledge to flow around the organization through overheard conversations and spontaneous meetings. Pairing delivers the same benefits, especially when practiced promiscuously. When you regularly switch up who you’re working with, you’re forced to both share and learn knowledge acquired by your pair in the weeks prior. Pairing also helps spread organizational values and culture organically, especially when someone new works with someone well-established in the shared values of the group.

Pairing also helps keep developers from drifting away unnoticed. When everyone is in an office together, it’s easier (not easy, but easier) to notice when someone is becoming frustrated, disengaged, or despondent, and to intervene before it’s too late. Working alone remotely makes it even more likely for someone to drift away, but pairing is an almost perfect foil. It’s hard to disengage and start trawling job boards when you’re on Skype and sharing a text editor with another developer, and pairing promiscuously keeps you regularly connected to everyone else in the organization.

In the InfoQ article remote working works Tom Howlett explains how he uses pair programming to collaborate and share information when working from home:

I spend most of my day Pair programming remotely with screen sharing or other tools such as tmux. It beats sitting side-by-side by far. I’ve heard many people do this even when they are in the same office. You are connected but still retain your own desk and setup.

What about when the whole team wants to get together to work on a problem together or discuss the next steps. We use one of the online tools to talk and share screens and again it’s nice to stay at the comfort of our own desk. It can be a lot simpler than trying to find a meeting room or a spare whiteboard.

When you want to do remote pairing you need to arrange tools to make it possible. In the blog post the best remote pair programming setup Brett Chalupa states the requirements for what he calls "the ideal remote pairing setup":

  • Fast - the host and guest should experience minimal lag when typing, as if they were on the same computer.
  • Easy to configure - any two people should be able to get setup and configured without much difficulty.
  • Quick to start - it should not take more than two minutes to start the pairing session.
  • Use of the tools we know - it should take advantage of the editors and shells we already use, not introduce new ones.

Based on these requirements the following tools are used at FullStack:

  • tmate for terminal sharing
  • Google Hangouts for audio conversations and screen sharing
  • Vim for text editing

McCrary also suggests to use tools like tmate, Google hangout or Zoom for sharing terminals for pairing. Alternatively you can standardize your development hardware:

Everyone [at Outpace] has a computer running OS X and, if they want it, at least one 27 inch monitor (mostly Apple 27 inch displays or a Dell) with a resolution of 2560x1440. Since everyone has nearly identical hardware and software we are able to pair using OS X’s built-in screen sharing. This allows full sharing of the host’s desktop. This full desktop sharing is the best way to emulate working physically next to your pair. This enable the use of any editor and lets you both look at the same browser windows (useful for testing UIs or reading reference material). With decent internet connections both programmers can write code with minimal lag. This is my preferred way of pairing.

Philippe Bourgau described in his blog post from zero to pair programming hero how they tried tools for remote pair programming when a remote colleague joined their team:

At the beginning, we were using Lync (Microsoft’s chat system) with webcams, headphones and screen sharing. It works, but Lync’s screen sharing does not allow seamless remote control between Paris and Beirut. Here is how we coped with this :

  • Only exceptionally use Lync’s "Give Control" feature : it lags too much
  • Do small submits, and switch control at submits
  • When you cannot submit soon, shelve the code on perforce (you would just pull your buddy’s repo with git), and switch control

As a result, Ahmad became productive a lot more quickly. We are not 2 sub teams focusing on their own area of expertise, but 1 single distributed team sharing everything.

Not everybody can or wants to pair all of the time, and there might be good reasons to do some of the work not in pairs. McCrary calls this soloing. He provides the following tips to get solo time:

One way to introduce solo time is to take your lunch at a different time than your pair. This provides both of you and your pair with an opportunity to do a bit of soloing.

Other short soloing opportunities happen because of meetings and interviews. It isn’t uncommon for half of a pair to leave for a bit to join a meeting, give an interview, or jump over to help out another developer for a bit.

Soloing also happens as a result of uneven team numbers. If your team is odd numbered than there are plenty of opportunities for being a solo developer. Try to volunteer to be the solo developer but be aware of becoming too isolated.

In the blog post how we do it: remote pair programming Jeffry Hesse shared experiences from a remote pair programming experiment done by Michael Prescott and Chris Wilper. Some of the experiences that they mentioned:

Wilper: Overall, I found pairing to be a positive experience, and there were several clear benefits. Most notably, it helped to break down the knowledge silos.

Another advantage was that it lowered the barrier to communication.

The two main challenges I noticed with our pairing experience wouldn’t dissuade me from trying it again, but they’re worth mentioning.

First, on pairing days, I was more mentally exhausted by the end of the day. I attribute this to the need to focus on the development task while maintaining communication with the other person. Second, I think development was ultimately a bit slower than it would have been if we’d been acting alone. This makes intuitive sense, and it’s the price we chose to pay for breaking down the knowledge silos that could have easily formed otherwise.

Michael: Part of the price of admission is that someone’s going to watch you blunder around in your weak spots. Chris and I both simultaneously realized we were shy about revealing we could never quite remember that mock expectation API. But a corresponding benefit is that the partner can point out tool-use tips that wouldn’t ever be communicated other ways (e.g. IDE navigation or refactoring shortcuts, favorite karaf commands and so on).

In terms of how to use this, I think it’s great for dissolving silos and spreading knowledge around. So, I’d recommend it for tackling areas that have a fair bit of design uncertainty, have inherently complex requirements, emergent logistical ugliness, or interfacing with complicated third-party APIs.

Means explains how pairing helps them to have a distributed team which is striving towards empathy and egolessness:

Pair programming, it turns out, is a neat hack for hiring developers with very high emotional intelligence. Developers who seek out full-time pairing tend to be highly self-aware. They’re comfortable being vulnerable and admitting they don’t know something. They happily give credit to others where it’s due, and they mostly avoid the common software developer pitfall of trying to make themselves look smart at the expense of everyone else on the team.

Empathy, egolessness, and vulnerability will emerge organically across your team when you seek out developers with high emotional intelligence.

Rate this Article