Anyone who works on code and is part of a team is probably familiar with Pair Programming. Even if you don’t take one of the more organized approaches as described in this article by Birgitta Böckeler and Nina Siessegger, at some point you’ll sit down together with someone else behind a single screen and work on a code problem. Whether it’s a user story, or debugging an issue, or transferring knowledge, pairing is often a very effective way to get good results.
But what if you’re not in the same room? Or even the same country? Or what if you are, but COVID-19 forces you to keep a good 2 meters distance. My monitor is big, but not that big…
In my previous project our teams were split between Amsterdam and Nairobi, so we would regularly run into the issue that we needed to collaborate with some not even in the same timezone. So what to do?
It’s probably really hard, so…
This is usually the first thought when people face this issue. How can we really work together, on code, remotely? It’s probably hard to set up. So we don’t. Instead, we send bits of code back and forth over Slack. Which is super annoying since Slack will mess up the formatting, doesn’t do highlighting, and strips line numbers. So after doing about 5 minutes of this, we’ll give up. Let’s do screen sharing! That’s obviously better. Except that it’s not. Screen resolution differences may make everything extremely tiny, and if you add in a little video compression the other side is practically looking at little grey squares that used to be text. And if you’re on the receiving end, you need to ask the other party to scroll up or down, or open an extra file for more context. And then still, little grey squares…
It’s not even a problem
The *nix crowd among us will know that this has long been a ‘solved’ problem. After all, you simply combine
tmux on a shared dev server and you can have a multiplayer coding session, regardless of whose monitor is bigger. And it doesn’t suffer from video compression. Amazing!
Except that nobody really uses shared dev servers anymore. And barely anyone I’ve worked with in the past 15 years is comfortable using
tmux, let alone combining the thing with
vim, for (software) development! So, even though I’m comfortable using both, most other people prefer something that requires less escape-sequence-magic and ships with proper mouse support out of the box. It’s 2020, after all. Point taken.
So it is a hard problem?
As it turns out, it’s actually not that hard to get a perfectly usable remote pair programming setup, without having to resort to ‘obnoxious command line stuff from the eighties’. Let’s start with one of the most popular code editors of 2020: Visual Studio Code. I may be a Vim guy, but if I look at what people around me are using, Microsoft is doing something right. So when recently a Kenyan colleague (who uses VSCode) reached out to me with a Terraform problem, I did some Googling and quickly found the Live Share Extension Pack, also created by Microsoft. I decided to try it out. I entered
brew cask install visual-studio-code in my terminal, launched VSCode, and installed the Live Share Extension Pack. It asked me to log in with my Microsoft account (you can use your Github account as well), and that was it. Two minutes later my Kenyan colleague and I were having our first Live Share session and figured out the Terraform issue.
So it just works?
Mostly, yes. I didn’t have to set up any shared server, VPN, cloud service, or firewall rules. Just open your workspace in VSCode and click the ‘Live Share’ button in the status bar. Send the Live Share link to the person you want to pair program with (we still have Slack after all), and they can just click the link and VSCode will join the session in a new window. Suddenly you can:
- see the files that are open
- scroll independently through whatever file you want
- arrange the open files as you wish (split panes) without it affecting what the other party sees
- make line comments if you see something strange
- chat in the separate chat tab inside VSCode
- share the terminal (if the iniating party permits it. The terminal is read-only by default. Good call, Microsoft!)
- share a server (HTTP endpoints, DB servers, etcetera)
What about video/audio?
Live Share also ships with an audio plug-in but I haven’t gotten that to work reliably. But you can obviously combine it with your favorite video/audio calling solution and still be happy. However, while collaborating like this, I’ve found that using video may actually get in the way.
There are several ways in which using video while pair programming can get in the way. Let’s start with the obvious: the video call physically takes up screen real estate that you could otherwise use for your editor. Not everyone has a triple-ultrawide-setup. So in reality the video call window gets minimized or put in the background, negating any benefit of using video.
However, there are also reasons why using video can even have a negative effect on collaboration altogether. Some people will be less efficient or focused when ‘being watched’. Many people have some bad habits that surface when they’re focusing on hard issues, whether it’s hunching over, pacing around, or biting nails; most people prefer to keep these habits private. Enabling video means having to actively think about not doing these things, which affects one’s problem-solving capacity.
Then there may be cases where using video influences a ‘power dynamic’. I could write a separate blog post on this, but you can probably imagine that someone living in a small 1-bedroom-appartment and working from their kitchen will be less enthusiastic about ‘showing off their home office’ than someone who actually has a dedicated home-office. These things matter. Also, that’s why virtual backgrounds are useful.
All in all, video can help or it can get in the way, depending on who you are, and who you are collaborating with. Personally, I’ve found that for pair programming I don’t really need video. But audio can definitely speed up things.
If you want to try out this setup, it’s easy. Get a colleague or friend, get some code, and make sure to both install VSCode and the Live Share Extension Pack. Also, make sure to check out the Live Share for VSCode Documentation for more extensive information on the possibilities.