How to Pair Program

Illustration by Siobhán K Cronin
Illustration by Siobhán K Cronin

Programming, like any art practice, is a performance. Our code reflects the physical and virtual environment it was created in, the culture of the team, the social weather of the room, the constraints of the toolchain and the target architecture, and the mood and facility of the performer at moment of strike.

We often imagine a solo act. It’s 2am and our hero works at a laptop at a small desk in a dark bedroom. To their left is an empty can of energy drink. Their level of concentration is so deep that you could stomp through with a marching band and they might not notice.

Or it’s 3pm and our hero is at their desk in a glassy, green-walled open-planned office. They’re listening to EDM, and everyone knows not to fuck with them when the earbuds are in. Distraction is so expensive these days.

Pair programming doesn’t fit these archetypes. Pairing is a graceful duet. It allows two programmers to combine their strengths and build something more thoughtful and cohesive than a single person can build. I believe it’s the fastest way to become a better programmer. And it can be a delightful experience.

Why pair?

Pair programming results in:

Who should you pair with?

In short: anyone.

Some options include:

Preparing to pair

Start by removing as many external distractions as you can. Put your mobile devices into airplane mode. Close Gmail. Turn on Do Not Disturb mode on your laptop. The best programming environment may be a separate account on the laptop that’s dedicated to focused work.

Get a clean glass and fill it with water. Drink the entire thing. Now, refill the glass and bring it with you to the pairing station.

Determine your roles. One person will drive, having control of the keyboard and mouse, and the other will navigate. (You can switch anytime you like.)

Product decisions will emerge as you code. Who will have the final say on these? Is that person within reach?

Everything happens on one monitor (or two mirrored monitors). The navigator should avoid doing side work on a mobile phone or laptop of their own during the session.

The navigator is responsible for deflecting any potential interruptions by other team members.

The navigator is responsible for monitoring any obstacles to development and noting opportunities for improvement of the toolchain. If a common step requires too much energy in the form of mouse work, commands, or keystrokes, make a note of it.

Agree on the development software and key mappings you’ll use. A tried-and-true development environment that is well understood by both of you is much better than a fancy new and shiny one. Efficient pairing depends on alignment around the development environment and key bindings. Role switches during the session should feel super fluid and not require any additional switchover time within the environment.

Clean your workspace, including the monitor.

You will need:

Now you can begin the pairing session.

WPA-era pair weaving

WPA-era pair weaving

During the session:

Optional practices

Traditional Shaker pair knitting

Traditional Shaker pair knitting

Programming requires creativity, discipline, and patience. Pairing is a great way to develop all three. It is a performance practice and a skill in its own right. And it’s fun!

Thanks to Siobhán K Cronin, Patrick Ewing, and Erik Hanson.