Pair Programming: Taking turns with your pair
In pairing, figuring out how to take turns if you are working on a hard problem is it’s own hard problem.
Pair programming, two people working on code, in sync, is heavily reliant on the people in the pair being able to take turns.
Frequently switching back and forth ensures that both people stay engaged and know what is going on. This means that when a pair hits a problem or some tricky parts of the code, there are two brains actively working together to sort it out.
In this post, we will look at a few different ways to take turns while pair programming and how to communicate about it so that different people with different coding styles and different personalities can find some common ground. Although this post is written from the perspective of pairing on code, there are hopefully some good ideas in here for other types of pairing such as pair design or pair testing too.
You’ve been successful as a pair if each person feels that the pair has found a good balance in contributing ideas, typing at the keyboard and each has an ownership stake in the code that’s been written.
As a reminder, in pair programming, the driver is the person typing while the navigator observes what the driver is typing and is looking slightly ahead. Think of someone driving a car while another person is looking at the map and directing. The goal is for the navigator and driver to switch off fairly frequently to ensure both have their heads in the code and are contributing.
Set a goal for the session
When you begin the pairing session, talk about what it is you want to achieve. Think of it as setting up a road trip. Both of you will need to know where it is you are going.
The difference here is that it matters less that you reach the end goal in this one session. What matters is that you and your pair are getting on the same page about where you are going. This will set you up to talk about how you want to take turns.
If your goal as a pair is to get better at taking turns, it will be easier to pair on code that each person knows something about. It’s not that you can’t pair on code that only one person knows, but it will be easier and less frustrating for you both.
Using a timer
If you are new to pair programming, it can feel overwhelming to suddenly be sharing your every thought about the code you are writing, much less figure out where to hand off the typing. The easiest way to make sure that you are switching it up is to each type for a set amount of time. Plan to switch off at least once an hour, any longer than that and it’s not really pair programming anymore. (Half a day is way too much time.)
My favorite way to switch off by time, is to use Pomodoro. Pomodoro is a technique where you work in cycles of 25 minutes focused on a task and 5 minutes doing something else (checking email, telling your boss how much you love pair programming or whatever. There are apps that will do pomodoro timing for you.
Switch off with a list of tasks
If what you are working on lends itself to a small list of tasks (3–5 things), this can be a handy signal to switch up driver and navigator.
I like thinking about setting up a small list of tasks as if I were planning a day on the road:
“I like taking that right turn at Albuquerque”
“How about stopping for lunch at El Taoseño?”
“Sure, we should probably put gasoline in the car before we get started.”
“Ok”
These tasks give you a loose plan and also a way to switch between driver and navigator. Every time you check off a task, switch who is typing. If a task ends up taking longer than you thought, take a break part way through and switch who is typing.
Switch off when it’s time to Google
If there’s one thing every coder has to do at some point, it’s to do a search. It might be that you have to search through some docs or that you’ve hit some weird error neither of you has seen before and wtf is it even saying?
When this happens, chances are, the person who’s been typing could use a bit of a break so it’s a good time to switch off and let the other person in the pair have a go.
Ping pong with TDD
Traditionally, when pair programming is done with test driving, ping pong is often used for switching back and forth. Test driving is the practice of writing a failing test before writing any implementation code. Once there is a failing test, just enough code is written to make the test pass. This also gives pair programming a natural flow. Here’s how it works.
Person A writes a failing test
Person B writes code to get the test to pass and then refactors the code
Person B writes a failing test
Person A writes code to get the test to pass and then refactors the code
This flow is why pair programming and test driving go together like peanut butter and jelly, but that can be a lot to put together. If you are comfortable test-driving, this will probably be your jam, but if not, don’t worry, there is a still a way to try out this flow.
Ping Pong without TDD
At this point, figuring out where to switch back and forth is dependent on the type of code you are writing and how you are proceeding through the code. For example, in the case of a web app, a few different ways to divide up could be:
Front-end/back-end
Person A implements an api endpoint
Person B hooks up the front-end
Person B writes another endpoint
Person A hooks up the front-end
Write code/refactor
Person A writes the simplest implementation code to get something to work
Person B refactors it
Person B writes implementation code
Person A refactors
Using a pairmate to signal who is driving and who is navigating
A pair mate is something small that gets passed back and forth between the driver and navigator as a way to signal who is typing and who is not. It can be a small stuffed toy, a fidget spinner, or anything small you can pass back and forth. The navigator holds on to the toy as a signal that they are not typing.
Conclusion
The tips in this post should help you get used to taking turns in a few different ways while pair programming. Setting an initial goal will help you both to know where you are going for the session. Taking turns in different ways will help you find your way to easier switching off so you can get to a good flow state in your pair.
Once you are both used to taking turns, you will have to do less work and spend less time thinking about how switch off or make the pairing equitable. When you reach a flow state together, you are both focusing on the problem you are solving, the moves and switching off comes more naturally. This flow state is what pairing is all about.
Next time in pair programming: Maximum overdriver
We all know the pair who can’t keep themselves from typing. Sometimes we ARE that pair. Sometimes, we spend a day gathering patience while we work with that pair…
