When the entire company is working from home, pair programming is not only possible but even more valuable. If you were practicing it face to face, why not continue remote? If you weren’t, why not try?
My team did a series of remote pair programming sessions in during the last month or so, and I want to share a few tips from that experience.
Tip
If you’ve never tried pair programming before, here’s a good primer.
Why you should try remote pair programming
Remote pair programming has all the same benefits of regular pair programming: knowledge sharing, better code, instant code review. And let’s be honest: remote work isn’t going away. It’s probably only going to become more common. So you could think of remote pairing as building a skill that helps prepare you for the future of work.
But it’s not only about the code. I’ve also found remote pair programming helpful for keeping the bonds with my teammates strong when we’re all working from home.
How to get started
At first, it would be unclear when to do remote pair programming and how to plan around it. It’s normal, and as for any cultural shift, it helps try it in small but regular portions to develop a sense for it. We found backlog grooming sessions to be a good place to identify issues that are candidates for remote pair programming. It helps to avoid overbooking during sprint planning as well, as at that point you know that two people would be looking at that issue. To have a good feedback loop we created a Confluence page to share experiences and we take time to reflect on remote pair programming during retrospectives.
Yes, just three steps:
- Identify issues-candidates for remote pair programming during backlog grooming.
- Factor in shared time during sprint planning.
- Include RPP feedback into sprint retros.
Those steps should be enough to kickstart the process and enable its further fine-tuning for your team.
Before your pair programming session, do some preliminary research about the issue you are going to work on together. Still, be ready for long (and longer than planned) sessions if you investigate a tricky bug. Don’t leave your partner to finish things up on their own.
There are various ways to approach remote pair programming. Our team found free-form collaboration to work fine, but if you feel a bit of structure would keep things moving along more smoothly, here are a couple of classic ideas to try:
- Driver/Navigator: The driver works with the code and is focused on careful implementation. The navigator is there to brainstorm and discuss, do real-time code review, and help keep the bigger picture in mind. Swap every 30 minutes or so.
- Ping-pong: This is a test-driven development type of approach when one participant writes a failing test and another makes it pass by updating the code to meet whatever standard the test is looking for. Then swap.
During the session, try to write down what worked and what didn’t. Pair programming is a skill, and like any skill, it grows much faster when you have a proper feedback loop.
Tools of the trade
Let’s look at a few specific examples of the tooling for remote pair programming and their usage. I broke them down into levels of “synergy” as a (quite subjective) measure of how much they aid collaboration. The higher the level, the more it departs from the classic Driver/Navigator model but I find those higher levels smoother and overall more productive.
Level 0
Zoom, Google Hangouts, or any other video-conferencing tool with screen-sharing would do. Sometimes it steers remote pair programming into a “follow the leader” mode, and you might want to ensure Driver/Navigator role swap from time to time even if it involves a bit of “git pull/push” ping-pong. I found it useful to keep the project open in my IDE even when we don’t switch to quickly reference things without disturbing the driver.
Level 1
Many video-conferencing tools give you an ability to temporarily control the input of another participant’s machine. If yours doesn’t, various forms of Remote Desktop control can come to the rescue. When working in terminal code editor, tmux is capable of sharing sessions as well.
As this ability proved itself handy for quickly demonstrating and testing ideas, the market responded with specialised tools (in no particular order):
- https://www.coscreen.co/
- https://pop.com
- https://www.use-together.com
- https://tuple.app
- https://www.teamviewer.com
Level 2
The most smooth remote pair programming in my experience comes from true collaborative editing rather than handing control over back and forth. It’s all about comfortable and uninterrupted flow:
- The ability to personalise your environment the same way you’d customise your own IDE. Theme, shortcuts, and window placement could be as important for productivity as, for example, using your beloved alien-looking mechanical keyboard.
- It’s easy to reference other parts of codebase quickly without interrupting your partner, and bring them up-to-date with zero overhead.
- You can temporarily work in parallel! Once in awhile, there comes a moment when the next step of implementation is crystal clear but requires some coding in different parts of the codebase. It’s still worth doing a cross-review afterward, but it just feels better this way vs. going serial.
There are a few tools available to enable such a workflow (in no particular order):
- https://visualstudio.microsoft.com/services/live-share/ – works with Visual Studio and VS Code. The web client is in the preview stage.
- https://www.saros-project.org – IntelliJ, Eclipse
- https://www.codetogether.com – VS Code, IntelliJ, Eclipse
- https://floobits.com – IntelliJ, Atom, Sublime Text, Emacs, Neovim
- https://teamhub.dev – IntelliJ, VS Code, Atom
Tip
Be mindful of data security and make sure your company and your tool policies align. For example, Floobits syncs the code with the remote server in order to work.
Final thoughts
Pair programming is about the synergy of collaboration, not about just sharing space and time. Don’t be tempted by unrelated tasks, even mechanical, when listening to the partner. I made this mistake once and it almost ruined my usefulness during the session.
It might not work for you 100% of the time but just give it a try. In my case, every single session felt like a judicious use of time.