Two parts remote, one part flex - Pairing
Techniques and tools for continuing your pairing practice whilst not being physically co-located.

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.

TL;DR

Tools

Tips

  • Agree breaks up front, zoom burnout is horrible
  • Live Share, make use of track participant - you see what they see
  • Pin point code by line number (they can't see where your finger is pointing)
  • Live Share audio is sketchy (could just be us) but very rarely got the audio to work
  • If Live sharing, consider knocking off camera - the code and problem are the important part
  • Consider whether the pairing be done asynchronously - Long distance ping pong
  • Understand that work days might be non-linear
  • Asynchronous pairing can be utilised for job sharing too

Pairing Tips

Productivity and breaks

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 unsure as to how often you feel like having breaks, try something like Live Share Pomodoro, Cuckoo Timer or Pomo Timer to work in 25 minute blocks.

Tracking participant and describing positions

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.

Asynchronous Pairing - Long distance ping pong

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.