Posted on Jul 18th, 2020 by James
The concept of Pair Programming focuses on those two checked in minds. As organisations adapt to remote based workflows, the concept of how those two minds are "checked in" has, in some cases, had to adapt.
In this blog I outline some of the techniques and tools we've tried for continuing pairing practice whilst not being physically co-located.
Even in a non pairing context, being on lots of Zoom calls throughout the day can be really draining.
Agree up front how long each pairing session is and take breaks from the pairing and the screen. If you're using Zoom we've found that leaving the mic muted and video turned off during the breaks is the best approach.
If you're using Live Share to pair remotely, it can operate in a manner such that both engineers can edit code independently (like how you might when editing a shared Google Doc) but for pairing you might need something a bit more synchronous.
With Live Share you can "track a participant" in order to see what they're seeing. We found that to be better for pairing than editing code independently and potentially treading on each other's toes.
Sharing the server and terminal is also a great way of "seeing what they're seeing" as you code together
Another tip is to remember that your pair cannot see your finger and where you're pointing. I've lost count of the amount of times that I've been pointing at my screen and poor Ellie has been left guessing what I'm going on about. Articulating a change or update by the line number, function name or variable can really ease that.
This one might get a bit of flack but consider whether your pairing has to be done real time.
I'm a big advocate of embracing non-linear workdays. (More on this in a future blog post) or maybe you have team members on different time zones. Either way you have some availability gaps. Asynchronous pairing might be your solution to maintain code quality, communication and have the same pairing outcomes.
The Ping Pong Pairing model works really well in async remote scenarios. In this scenario one person (the first person) would work in isolation creating the tests for a particular function and commit/push their failing tests. Some time later the pair individual would run the tests, observe the failure and work through the implementation, just enough to get each test passing.
Not just applicable for the new remote world, this approach can really open up your talent pipeline to job share individuals as well. The code effectively becomes a really detailed handover document.