Remote Pair Programming in COVID-19 Times

Pair programming in pre-COVID 19 used to be somewhat easier because we were all in the same office space. We would sit with our pairing partners at their desks and we would rotate the roles of driver and navigator at some unquantified time and take irregular breaks. Didn’t really bother us because we still got good stuff done and were able to pair and communicate fairly efficiently thanks to face to face communications.

COVID-19 changed all that, so I thought I will share some of my experiences of remote pairing and how are we improvising in these trying times.

We’ve been working from home since about March and for the first couple of weeks, pairing proved to be a nightmare. We’d get on Google Chat video calls and half the time try not to talk over each other due to delays and lags in the calls.

We also didn’t really have a structure that would allow us to do anything remotely (no pun intended) pairing like. One of the pair will fire up the IDE and share their screens on Google Chat which the navigator will “follow” but really couldn’t contribute to effectively. We struggled with tools, whilst in the office it didn’t matter what IDE someone used, trying to pair remotely with these differences became quite painful.

Most of us either Visual Studio or VS Code with the exception of one developer that loves Rider and whilst VS has some good support for remote collaboration like LiveShare, Rider has none (as of this writing anyway). Initially, even LiveShare was quite buggy for e.g. in a remote session, the session joiner wouldn’t be able to run the tests or see the tests running. I chased Microsoft on this and they eventually fixed this but that only held for a while.

So that our pairing time doesn’t get wasted on grappling with buggy tools & we can pair regardless of IDEs, we’ve created the following “process” to make remote pairing more pragmatic, efficient and effective.

1. We only pair on significant pieces of work and when feasible. Remote work increases your video chat time quite a lot as it is, we don’t want to burn people out with multi-hour remote pairing sessions if we don’t need to.
   
2. We use LiveShare as far as possible but push comes to shove, we switch to shared git branches to do the collaboration. Essentially, what this means is that if I as the driver make changes to the code in a local branch, I can push the branch to my fork of the repo, my colleague as the new driver can then add my fork as another remote, do a fetch all, switch to the branch that I had pushed in and carry on working on top of the changes I’d made. Another reason to use Git!
   
   git remote add <colleague's-name> <Url to the git repo>
git fetch --all
git checkout <name-of-the-pushed-branch>
   
   Once this is done, the driver will then share their screen on Google Chat video call so the navigator can see what they are doing and suggest ideas. Finally, a PR is made out of the final changes from this “shared” fork.
   
3. We use Pomodoro technique to do focussed pairing sessions for 25-35 mins max and then take a 5-10 min break. If you are gonna have multi-hour remote pairing sessions, you NEED more regular breaks to decompress and zoom out of the problem to see the bigger picture and hopefully come up with a new insight to solve the problem or a refactor that will make the code cleaner or just chill!
   
   At the end of every Pomodoro session, the driver will push the work in progress to their remote, the navigator will pull down the changes and prepare their local branch for the subsequent Pomodoro session (as described in point 2 above). The new session will begin with the roles switched around.

We’ve been working like this for a few months now and will be until we return to office but I have to say this has worked fairly well for us so far. The remote aspect of it has reduced in significance, we are still pairing on problems where there is real benefit in doing so and developers can still use whatever tools they like. Seems like a win-win to me, just with a bit of pragmatism!