Pair Programming: Taking turns with your pair

Marlena Compton
Mar 21, 2018 · 6 min read

In pairing, figuring out how to take turns if you are working on a hard problem is it’s own hard problem.

Image for post
Image for post
Photo by Konuzelmann Thomas

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

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

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

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

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

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

Front-end/back-end

Person B hooks up the front-end

Person B writes another endpoint

Person A hooks up the front-end

Write code/refactor

Person B refactors it

Person B writes implementation code

Person A refactors

Using a pairmate to signal who is driving and who is navigating

Conclusion

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

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store