Since I became a Cookie, we’ve been remotely pairing intensively. Here’s how we are doing it and my opinion on the matter.

Pair programming picture

When I joined CookiesHQ, Nic had planned for us to start remote pairing on a project for a whole week in order to get me up to speed on the existing codebase, technologies and methodologies. I felt it was a privilege to get such a introduction to an existing project, being used to the freelancer’s blues, “here’s the code, do your thing”. Also, I’ve done pair programming before, but never remotely, so this had the extra appeal of the challenge, since I live in Spain, speak another language, and our success establishing a way to do it would mark the way we work together.

On the technology


Our first approach was trying Floobits, which allows the user to create public or private (not for free users) workspaces which you can share and allow others to join. You can then work on the browser, as the workspace includes an editor, a chat panel, and a terminal panel. It also allows you to share your desktop or terminal editor directly, as it integrates with Sublime Text 3 and Vim. Even more, it has a Google Hangouts extension that integrates the hangout window with the virtual workspace, so you have everything together. The major drawback was realising that the code will be on Floobits servers, and we can’t afford that for our clients’ projects or our own, so we discarded this option.

Ups: compatible with lots of editors.

Downs: third party middle-man, you need a paid account to have private workspaces.


Then we went for a VPS, following this article on Pairshaped. Basically what you do is mount up a Linux VPS to which each coworker will connect via SSH and with the help of Wemux, an addon for Tmux with which you can set up several terminal screens and share them, then start working with Vim, allowing both user to work in the same window. The only hassle would be having to bring back code to your local machine, but (as you probably already kew) Git covers that.

Ups: Secure, fast and reliable.

Downs: Assumes you code on Unix with Vim. Switching to your local code requires you to commit and push. You need to pay and setup a Unix machine ( DigitalOcean or Linode offer cheap and reliable machines).

To speed things up and do quick pairing sessions or show/consult code in a fast way we started using Tmate, which is a fork of Tmux that allows the user to share a terminal, generating a SSH address that you send to your partner. He will connect to your terminal via SSH and be able to interact with it, too. Normally, the connection will be made through servers, but you can setup you machine to be a server, too.

Ups: Fast and reliable.

Downs: Having someone able to write on your terminal might be dangerous }:-)

Screen sharing is always useful

Nic is a Vim user, so he was very comfortable using the VPS or, but since I’m not Vim fluent (yet), when I needed to share my code with him I just use the screen sharing feature on Google Hangouts, and so does he when he needs to show something that is happening on his browser. The drawbacks are obviously the greater latency, and not being able to see your coworker’s face when he shares his screen with you.

Ups: Anything goes!

Downs: Slow

On the methodology

I love pair programming, so that pretty much sums my take on this. Anyway, doing it remotely adds some overhead (do the hangout, setup connections, internet connection reliability, …) that makes it a bit slow in the beginning, but when you get used to it, it just becomes natural. I need to get used to Vim (any advice?) to be able to drive (and code) more efficiently with our setup. Also on the plus side, when you are in a hangout you can’t switch contexts easily and you get isolated from what’s around you, so you get super focused on the work, which is great.