Better Remote Pair Programming

Pair pro­gram­ming is the con­cept of two de­vel­op­ers work­ing to­gether, in real-time, on the same code base on the same de­vice. There are some vari­a­tions and tech­niques that vary from or­gan­i­sa­tion to or­gan­i­sa­tion around pair pro­gram­ming, but to me, it boils down to the con­cept of Two brains are bet­ter than one, de­pend­ing on the prob­lem”. A spin-off is mob pro­gram­ming, where the whole team works on the same thing.

Pair pro­gram­ming is ideal when on­board­ing a new de­vel­oper into a code base by solv­ing a prob­lem, like build­ing a new fea­ture or fix­ing a bug. In day-to-day work, pair pro­gram­ming is help­ful in cap­tur­ing bugs that a sin­gle de­vel­oper would­n’t had no­ticed. It’s also great for rea­son­ing about high level strate­gic parts of the code to­gether with an­other de­vel­oper.

This post is­n’t about the pros and cons of pair pro­gram­ming (there are a ton of ma­te­r­ial to di­gest about that on­line).

But what about re­mote work and pair pro­gram­ming? Since the phys­i­cal as­pect of tra­di­tional pair­ing is one of the main pros, it has been hard to repli­cate when all de­vel­op­ers are work­ing re­mote.


At work, we started a pro­ject where we needed to start off with a whole new code base. The task at hand in­volved rewrit­ing an ex­ist­ing web fron­tend in React views, built on a func­tional re­ac­tive soft­ware pat­tern. We also had to in­te­grate it against our ex­ist­ing Meteor back­end, for data load­ing and user au­then­ti­ca­tion. Finally, it needed to talk with an in-house WebRTC ser­vice.

So we had a few un­knowns:

  1. How do we han­dle TypeScript com­pi­la­tion in the ex­ist­ing code base?
  2. How to in­ter­grate new React views in the Meteor fron­tend?
  3. How to drive the fron­tend state from the Meteor back­end?
  4. How to man­age fron­tend state and WebRTC con­nec­tions with the func­tional re­ac­tive pat­tern?

I had an inkling on how to solve 1) and 2). I had very lit­tle ex­pe­ri­ence in 3) and 4). A col­league, who was a big dri­ver be­hind the func­tional re­ac­tive pat­tern, had ex­per­tise in 3) and 4). But due to our re­mote setup at the com­pany, we could­n’t sit down for a hack day and flesh things out to­gether.

The prob­lems

The prob­lems with re­mote and pair pro­gram­ming are thus:

  1. Not be­ing in the same phys­i­cal space — tricker to have high band­width com­mu­ni­ca­tion.
  2. Cannot work on the same com­puter.
  3. Cannot with ease see what the other de­vel­oper is see­ing.

Okay, Johan”, you say. You can rem­edy at least 2) and 3) in that list with re­mote con­trol ap­pli­ca­tions and screen­shar­ing”. Yes you can! That’s pre­cisely what this post is about ✨

The so­lu­tions

What if I told you that you can pair pro­gram like you’re pair writ­ing on a Google Doc, right from in­side your code ed­i­tor?

Well, you can.

Me and my col­league landed on these two tools:

  • VS Code
  • Slack voice call

Co-operating on the code

This was the deal breaker for us: how to co-op­er­ate on the code base with­out in­tro­duc­ing old school so­lu­tions like re­mote con­trol soft­ware? We wanted this to feel like your own ed­i­tor, even you were re­mote.

Luckily, the de­vel­op­ers be­hind the pop­u­lar ed­i­tors Atom and VS Code have worked on this.

We’ve only used VS Code, so I’m go­ing to cover that only in this post.

VS Code’s Live Share works like this:

  1. One de­vel­oper hosts a ses­sion on their com­puter, by in­stalling the ex­ten­sion.
  2. The de­vel­oper hits Share” in the ed­i­tor’s bot­tom sta­tus bar. VS Code will ask them to auth with GitHub or Windows Live (yea, right…).
  3. Once that’s done, VS Code puts a link in the clip­board, and the de­vel­oper can send it to co-work­ers. Hitting the Share” but­ton again brings up a menu to man­age the shar­ing ses­sion.
VS Code

You can now:

  • Co-edit
  • Co-debug
  • Share a server
  • Share a ter­mi­nal

When your co-de­vel­oper joins, they can nav­i­gate your work­space right from within their own ed­i­tor.

Talking along the way

The so­lu­tion here is to set up a voice or video call on the side of VS Code or Atom. It’s re­ally great to be able to talk along­side work­ing with the code with your col­league.


Just be­cause you’re work­ing re­mote does­n’t have to mean that you’re on your own” with tricky code prob­lems. It’s to­tally doable to pair pro­gram when you’re stuck, or need guid­ance in a new sys­tem or pro­gram­ming lan­guage. Existing so­lu­tions in­clude screen shar­ing and re­mote con­trol and all kinds of bor­ing se­tups. Having code shar­ing right from within your ed­i­tor is re­ally great, which makes it eas­ier to fo­cus on the code and col­lab­o­ra­tion. The fact that you are work­ing re­mote won’t mat­ter when your col­league is just a link away from your ed­i­tor.

Some fea­tures are still lack­ing in the VS Code ex­ten­sion to make it feel just like my own ed­i­tor”. The most an­noy­ing one is that the guest is­n’t able to jump be­tween files. And I’d love a nicer way to high­light Here I am!” from within the ed­i­tor, since you’re prob­a­bly gonna jump around in the pro­ject struc­ture.


  • On the tech side, I’m not sure ex­actly how VS Code has built the code shar­ing ar­chi­tec­ture. There’s no open source repos­i­tory for the pro­ject, ex­cept for a doc­u­men­ta­tion repo. That’s too bad… The Atom folks have built their sys­tem in WebRTC, where the ini­tial hand­shake goes to their servers, but the ac­tual code shar­ing goes over Peer-to-peer con­nect to avoid any mid­dle men.
  • We ex­pe­ri­enced some weird bug in VS Code at the time of writ­ing where the text ed­i­tor would freak out when one of us hit cmd+z to undo a text in­put. The ed­i­tor would go hay­wire and delete most of the code writ­ten to that point. But then it was mag­i­cally re­stored.