Illustration by Heather Barron
I spend a lot of my time pair programming. I like that the feedback is immediate, I learn a lot, and, maybe most importantly, I have a good laugh with the person I’m working with. I’ll spend no time here convincing you to adopt pair-programming (although I’d recommend Kent Beck’s Extreme Programming Explained if you haven’t already read it). My advice, about all parts of life really, is to try everything and do what works best for you, not necessarily what a stranger tells you on the internet.
Below are some of the variations of pair-programming I seem to follow. I don’t usually decide which one to use, they just happen depending on who I’m working with or what mood we’re in at the time.
I should also say that these are my experiences as a remote developer.
The Passive Heckler
Person A wants to get opinions from Person B as they write code. Person B joins the call, but is doing other things too. They vaguely follow along with the other person and will chime in occasionally with “there’s a typo on that line”, or “oh, have you thought about this other approach?”.
It feels very similar to working in the same room as another person because you can just dive in and out of your own work and chat with a teammate.
The Active Heckler
Both Person A and Person B are equally invested in a piece of work, but Person A has an idea they want to implement and to get feedback on as they go. Person B agrees to watch over them and suggests ideas. This can be a useful way for Person A to get quick feedback on a spike and to create something half-decent from an idea they had that they weren’t too sure about.
I usually find that this is best for short periods of time (up to a half day) because Person B will start to lose focus if they aren’t engaging the typing part of their brain.
Pomodoro-Ping-Pong
Ping-pong pairing is traditionally where Person A will write a failing test and Person B takes over to write a solution that makes the test pass. The roles then swap, so Person B writes a failing test and Person A writes a solution. I see it as hard-core Test Driven Development, but I find that it’s a bit too strict and clunky to work for me. At some point I merged the approach with the Pomodoro technique, which is where you work for 25 minutes and then take a break (there’s a little more to it than that, but that’s how I use it).
The merged approach involves Person A programming and Person B guiding/contributing ideas for about 25 minutes, then they have a cup of tea or a chat for a bit and swap roles. Maybe they’ll go for 40 minutes or an hour before swapping, it just depends on what feels right—there are no rules, do what you want!
This approach is the one I use most often and has the benefit of being lots of fun to say out loud. On top of that it creates an image in my head of playing ping-pong with a tomato.
I assume these techniques are already in-use by others and probably called something a bit more appropriate, but they seem to have developed naturally over time for me. Try them out and let me know what you think.
RSS feed (Atom)