7 Remote pair programming best practices Q&A - Part 1
Remote pair programming brings surprising benefits to a team! Daunting at first, it is quite manageable with the good practices. Here are the first 2 of 7!
A few years ago, Ahmad and I worked together in a distributed team. Ahmad and Mohammad were working from Beirut while the rest of the team was in Paris. As you might know, this setting is a recipe for a split brain team. Practicing almost full time pair programming was the thing that kept the team spirit.
For the better and the worse, remote work is here to stay. Remote pair programming offers other advantages on top of improved team spirit. It enables people to work from wherever they fancy. Finally the introvert in me found it more sustainable than in person pairing.
A few weeks ago, Ahmad wrote a guest post about pair programming best practices. Let’s build on this to address remote pair programming.
💡 Remote or not, pair programming remains pair programming!
Most pair programming best practices also apply to remote pairing. This is not enough though, remote pair programming has its own challenges. Here are questions we often get from teams envisioning remote pair programming.
Lag is preventing us from remote controlling the screen, what can we do?
We were working between Paris and Beirut, where local connection was not always very fast. Slow typing, letters appearing in different orders, shortcuts that don’t work, different keyboard layouts… We know the problem!
To stick to local code editing, we would send the code over when we switched between driver and navigator. As a result, we would not switch as often as when doing local pair programming. Though not ideal, this was the best workaround we found.
Pomodoro technique
To make sure we shared the keyboard between parties, we used the Pomodoro technique. Every 25 minutes, we would take a 5 minutes break, and send the code over.
If code was in a good enough state, then committing was our preferred way to pass over the code. Otherwise, we would send a patch or pull from each other’s local git repo. It might be possible to script this and make the switch a breeze.
An extra second order benefit of this technique is that it pushed us to do small commits, which is already by itself a good thing.
Screen sharing
Seeing your buddy’s screen is important to understand what’s going on. Dual screen was key to make this work: one screen for the work, one screen for your buddy’s face.
Some screen shares, like Slack and Microsoft Teams have multi cursors. This is a killer feature to highlight code. At first, we very often found ourselves pointing to a line on the screen with our finger. This is one of the most frustrating thing to do when remote pair programming. Before multi cursors, we would end up saying things like “at line 64…”. This was a pain for everyone.
Other tools
Some tools promise an improved pair programming experience: Floobits, Saros for Eclipse, Live Share for Visual Studio or the new ones like Use Together. They let you concurrently edit code, which fixes the lag problem.
Unfortunately for us, we did not manage to get any of those to work:
- Saros was not a big enough reason for us to leave Intellij for Eclipse
- We could not use Floobits for company policy reasons
- As Java programmers, Visual Studio was not an option
- Use Together did not exist at the time
That said, these tools only synchronize editor windows of the IDEs. They don’t save you from sharing your screen, to see the test execution for example.
Other, like Ham Vocke, have reported success with TMux. If your team is not using an IDE, it’s a great way to work collaboratively on the same terminal.
NB: I’ve since then written a more detailed post going over the tools for remote pair programming. If you want more, it’s here: Best open source tools for remote pair programming
Pairing is tiring, what about remote pairing?
When I first started intense pairing, I felt a wreck at the end of the week. When we switched to remote pairing… it got worse! The extra effort to accommodate for video and headphone adds up to the mental load.
If done without care, it can ruin the team out. It’s important to stick to a sustainable pace with pairing too.
Here are my advices:
- Invest in the best material you can. A comfortable headphone will make a tremendous difference at the end of the day.
- Accept that you cannot be productive for 8 hours of pairing a day. 6 hours of local pairing is plenty, 5 of remote is as well.
- Don’t be afraid to take breaks as often as needed.
- It’s important to leave some time out for solo work to let introverts re-charge batteries. A time difference will actually help you. Why not use these early morning or late afternoon hours for deliberate practice? In the long run, it should make the whole team more productive (see Nobody ever gets credits for fixing problems that never happened)
💡 When remote pair programming, use time difference at your advantage to deliberate practice.
To be continued
This was the first part of a mini series about Remote pair programming best practices. In the next post, we’ll go over 5 more tips.
Leave a comment