Remote pair programming - three tools we tried

by Rabea Gleissner

My colleague, Federico, and I have done a lot of pair-programming recently - remotely, of course. He’s in Milan and I was working between the UK, Germany and Singapore. We tried several different tools, so I thought I’d write a review of our experience.

Most of the time, when I’ve been pairing with someone at Tes, we use a Zoom call and screenshare that way. That usually works well for pairing briefly - to discuss an approach or get help with a particular confusing bit of code. When pairing the whole day for many days, this can get tiring.

The problem is that it’s hard to quickly switch over between the driver, the person who is typing, and the navigator, the person who is reviewing. You’d have to push the code up to GitHub and switch over that way. Also, Zoom calls with screen sharing often make our laptops slow, so running tests can take ages. This can be great because it gives us time to catch up about what we did at the weekend and which TV series we should binge watch - but really, it’s not very effective.

So instead of screen sharing via Zoom, we tried out some other tools.

tmate

As an avid Vim and tmux user, I find tmate to be a great option. It has the same functionality as tmux, the terminal multiplexer, and it also starts an SSH session. That way your pairing partner can connect to your terminal session. Yes, that also means they have unrestricted access to your shell, so you really only want to do that with people who you trust. Alternatively you could set up a virtual machine to run your dev environment in.

You can install tmate with Homebrew on Mac and then all you need to do is start it with the command tmate. Your session is created and it shows you the address that your pair can use to connect. Very easy, light-weight and completely free!

The downside is that you cannot use any fancy code editors but you will have to use one that runs in your terminal - like Vim or Emacs. If you’re not familiar with one of those, then that’s a bit of a hurdle.

Floobits

Next we tried Floobits. The advantage of Floobits is that it plugs into several of the popular editors.

We tried it with WebStorm, because that is Federico’s preferred code editor.

To use this service you have to set up a Floobits workspace to which you upload your codebase. By default, the workspaces are public - so make sure you don’t accidentally upload any code that shouldn’t be seen by the world. You have to pay for private workspaces, but luckily Tes has a subscription which we used. Floobits plugs into any of the supported editors to connect to this workspace and keeps the code in sync. You can specifically select an option to follow one person to see what they are doing, which is how we did it. Federico was the driver and I assumed the navigator role and followed him.

In our trial it worked reasonably well but there were two downsides for us. One was that you can’t see when the driver is searching the codebase, navigating through files or doing any other editor actions that aren’t directly related to typing or moving around inside a file. So that was a bit annoying.

The second let-down was that you can’t share the console. So when Federico was running tests, I was asking him: “What are you up to now? I can’t see what you’re doing!” Turns out you can’t share the console on Floobits and I think that’s a major deal breaker. Thinking about how Floobits works, it makes sense that you cannot share a live terminal session. It hosts your code on a Floobits server and you connect to it. But without both being able to see the tests running it’s really hard to pair. We’d have to resort to sharing our screen on Zoom again which is what we were trying to avoid!

VS Code Live Share

Lastly we tried VS Code Live Share. Neither of us are using VS Code as our preferred editor but luckily Federico had his editor already set up with a few plugins so that it was in a usable state for him. All you need to do is install the Live Share plug in and then create a new session. Federico sent me the session URL and I connected to it. It was a lot easier to set up than Floobits. No private workspaces, no uploading of code… just press the button and start. So that was awesome. And we were also able to share the terminal view. Navigating files or searching in the editor is still not visible through Live Share but I guess you just have to communicate a bit more about what you’re doing.

It takes a bit of getting used to though, because you can follow the driver when they type or scroll through a file - but you can’t follow what they’re doing in the terminal. On the plus side, as the navigator you can scroll through the terminal session as you please, but if you try to do that in the files, the driver will have a bad experience because the file is scrolled for them too while they’re trying to type something. Sorry, Federico!

After using VS Code Live Share for a while, we suddenly started getting some strange synchronisation issues. Somehow all the new code that we added would be overwritten by an older version. Not sure what happened there - maybe it was a connection issue? But after that we decided to stop using it.

Which one was best?

For us, I would say overall VS Code Live Share won - it was the compromise that worked best for both of us. It was easy to start a session, you could share the terminal and the learning curve to use the editor is shallow. We did have the synchronisation issue but I would still give it another try again. Let’s give it the benefit of the doubt and hope it was a one-off!

Personally, I still think that tmate is miles better, because the sharing experience is exactly the same as if we sat next to each other. My partner can see exactly what I’m doing because the complete terminal session is shared including all of the various console windows I might have open. But the downside is that both partners have to be able to use the same code editor running in a terminal - and those can be a bit more challenging to learn.

One aspect that each team needs to evaluate for themselves is privacy and security when using these tools. It could be that your code is highly sensitive and can under no circumstances be shared with any third party. In that case it might be better to refrain from using any of the above tools. Ultimately it always comes down to project requirements and personal preference!