12 May 2020
Working remotely doesn't necessarily mean working in isolation, but it does tend to impose it as a default. Seeking out more pair-programming sessions is one of the ways I'm compensating. Here's what I've learned so far:
You wouldn't show up to a physical pairing session unshowered. I consider connection, audio and video quality to be the hygiene of remote work. My setup is:
80mbps/20mbps FTTC connection via Zen Internet. If decent fibre is available at all in your area you have no excuse. If it isn't, set up a strong 4G connection. Install an external antenna and a mast if necessary.
Logitech C920 camera. Nothing super-fancy but the autofocus is good. I consider HD (1920x1080) to be a reasonable standard; to get this in Zoom, you'll need to go to Settings and turn on HD Video.
LED light panel. You wouldn't show up to a physical meeting and lurk in the corner with the lights off, shrouded in darkness. Unless your desk faces a window and it's light out, get a light panel.
USB headset with microphone. Perhaps surprisingly, all bluetooth headsets (yes, including expensive "true wireless" earbuds) have noticeably degraded quality and much higher latency. Both of these will affect the quality of your communication in subtle ways.
Dual screens. I have the codebase open on a large screen, and the laptop open next to it with the video chat fullscreen. This means that my partner can see whether I'm looking at the code, or looking to them - a really useful cue.
Zoom. Whatever you think about their security or ethics, right now they have the best audio/video quality and reliability in the game. If your work is security-critical, obviously use something else.
VSCode Live Share. This is an absolute gamechanger. One of the worst things about physical pairing is having to use someone else's desktop OS / weird keyboard / custom IDE setup. It also tends to inhibit driver-navigator changeovers, which makes the communication less effective.
If you aren't already a convert, VSCode Live Share syncs code changes rather than sharing screen + mouse/keyboard inputs, so everyone uses their own system and own IDE, but sees code changes in realtime. You can also share local servers and terminals so you don't need to go through the work of getting the codebase working on everyone's machine. It's magic.
(It's also possible to get it to go out of sync, which can do weird gaslighting effects to the pair since you'll see different code. This has only happened to me once so far.)
Pairing gives you knowledge, oversight, and energy. That last is important, and a tired partner makes for an unpleasant session. While I'm setting calendar invites for 60 or 90 minute sessions in order to plan my day, I'm also sensitive to both my own and my partner's remaining energy. As soon as we're no longer buzzing, we're done.
I've found that my own stamina is only good for about 90 minutes at a time at maximum intensity. But that's enough to get a lot done. I'd rather break the pair and work solo for a bit at that point than pair at other than maximum intensity.
I tried three, just to see what would happen. The energy/focus wasn't really there - in a two-person pairing session you need to remain fully engaged all the time, but in a triad you don't. It can also be harder to make sure nobody is left behind (which will cause them to become disengaged, not only wasting their time but also draining the energy out of the session).
In physical pairing it's usual to trade the driver/navigator roles back and forth. One way to do this is using TDD - Alice writes a failing test, Bob makes it pass and writes another failing test, Alice makes that pass, and so on.
But in remote pairing, using VSCode, you can all drive at once. This works better than you might think. I've found that we settle into a flow where we 1) pick a feature, 2) both navigate, discussing the changes that need to be made (often writing a temporary list in a shared text file), and then 3) both drive.
At (3), you can actually race to write the code, editing different files, different functions in the same file, or even the same line - which is like being so in sync that you can finish each other's sentences. I have been known to correct my pair's typos faster than he can.
It's not always the right way to do things but it is absolutely awesome and you should totally try it.
Once you're used to finishing each other's sentences, you can get twice as many "cache hits" (where you already know the syntax for what you want to do, and don't have to context-switch to the API docs, your snippet library, or Stack Overflow).
If I'm mid-flow but have somehow forgotten how to get the current timestamp, I can write
if (??currenttime?? - myRecord.last\_updated > STALE\_RECORD\_MSEC) {
and carry on without even slowing down, and my partner can fix it with Date.now() on the fly. Fewer context switches mean happier developers.
You can do this with physical pairing, too, but it's much slower - either you have to pause and verbally ask, then type in the dictated code, or push the keyboard across the desk, or leave a loose end and (hopefully) come back to it when you're out of the flow.
I'll add more tricks to this page as I discover them. Drop me a line if you have ideas or want to try some pairing (I'm doing mostly Ruby and React right now, but happy to try to help on something else if you don't mind doing a fair bit of driving).