Three of a Perfect Pair

This post is about three approaches for remote pair programming that I recently learned to value a lot. They’re not perfect, but I like the King Crimson reference.

Come Prepared

Do all set up, check out, scaffolding or other basics, before you start pairing. If you’re debugging a complicated issue that needs a standalone reproduction, build that first, than use your pairing time to debug. If you’re continuing work on a feature, check out the existing or new branch first, start your development server, open the relevant files, start your unit test watcher, open the app, log in, or whatever else might be needed. Everything that is boring, where your pairing partner likely has nothing to contribute, should be done before hand. If you’re starting something from scratch, create the project (from a template first), initialize git and so on. Unless the point of the pairing session is to pick a framework or library, make sure that the new dependency is already installed and imported.

Use a Collaborative Editor

Use an editor experience where you can edit code at the same time. Something online like Glitch or, or some desktop setup like VS Code with Live Share. Use this to quickly change driver/co-pilot or suggesting single lines, not so much to work on different parts of the code in parallel. If you end up working in parallel, there’s a good risk you both make mistakes that are harder to find later, ruining the benefit of pairing.

Don’t be like me a week ago, thinking that Live Share doesn’t work for web development without a shared browser. Instead use the shared server feature and do (exploratory) testing in parallel.

When you’re exploring solutions to a problem you don’t yet understand well, consider using other collaborative tools, outside of code editors. With Excalidraw, Google Drawing or Miro you can sketch or scribble together (probably all more effective than sketching on paper and holding that in front of the camera).

Keep an ‘Improv’ Mindset

In improv (as in, improvisational, live theater/comedy), the “Yes, and…” rule encourages a positive attitude, accepting suggestions from others and building on top of them. When your pairing partner suggests something that sounds wrong, refrain from pointing out the mistake and try to roll with it. If it really is a mistake, they should realize that quickly enough. If its costly to try out, probe gently instead. There’s also a good chance that the suggestion is great, and you just didn’t quite understand it, yet.

In a recent pairing session, we were working on an image sampling task, trying to detect overexposure in video frames. At one point my pairing partner suggested to split the image into sectors and run the detection in each sector individually. At first I didn’t understand the point of that suggestion, but managed to refrain from rejecting it. After a bit more exploration we realized that these sectors would also provide much better feedback to the user – instead of saying “this frame is overexposed”, we could instead point to a specific sector. This improved the solution greatly, with very little code and runtime overhead.