Pair Programming

Early in my career, I thought pair programming had its uses—but believed two developers tackling separate tasks was more efficient. These days, I know better.

I’ll walk through The What, The How, and The Why of pair programming so you can fit it into your own workflow and reap the benefits.

🤝 The What

Pair programming, or pairing for short, is simply two people working on the same task at the same time. It could mean writing engineering requirements, fixing bugs, creating features, deploying, or even brainstorming on a whiteboard. Honestly, “pairing” is sometimes more accurate than “pair programming.”

🔧 The How

Some companies believe so strongly in pairing that they set up pairing stations throughout the office:

• Two keyboards
• Two mice
• A single large monitor or one for each developer
• All connected to the same computer

Each developer still has their own laptop for Slack, email, and the like. When it’s time to build, the pairing buddies bring a laptop to a station, plug it in, and work together until the task is done, taking breaks as needed. For remote teams, tools like LiveShare do the same thing—with the bonus of preserving your own editor settings and keybindings.

Here are three powerful pairing methods that usually beat solo development:

TDD ping-pong

Test-driven development (TDD) enforces thoughtful design in small, incremental steps. The result: cleaner, more modular, loosely coupled code. It also provides higher confidence, faster feedback loops, and natural opportunities to refactor.

In simple terms, TDD has three steps:

1. Red: write a test that fails
2. Green: write the code to make the test pass
3. Refactor: clean things up as long as the tests stay green

With ping-pong:

1. One person makes it red
2. The other makes it green
3. Either or both refactor
4. Swap roles after one or more cycles

Every tiny detail of the code and tests has two sets of eyes throughout the entire process.

• In person: pairing stations work great though you can get away with passing a laptop back and forth in a pinch
• Remotely: a collaboration tool like LiveShare is essential

Driver / navigator

Ever been in a “pairing session” where someone shares their screen, bounces around files at lightning speed, and basically codes while you watch? I've been on both sides a few times—it's not a great use of time. One person disengages, the other loses out on their partner’s brainpower.

The driver–navigator split fixes this. The driver controls the keyboard and mouse, while the navigator instructs. When driving a car, you don’t make a turn unless the navigator says so. When programming, you don’t change files without their go-ahead.

This dynamic forces constant dialogue:

• Driver: “Wait, what do you mean?”
• Navigator: “Try it this other way.”
• Driver: “Whoa, how’d you do that?”

Both learn. Both grow. Knowledge gaps shrink fast. Navigators sharpen communication skills, drivers sharpen listening skills.

• In person: at a pairing station, conference room, or even shoulder-to-shoulder at a desk
• Remotely: any screen-share works—just make sure the navigator can read the text

Pair Review

Sometimes even the tiniest feature ends up stuck in pull request (PR) purgatory for days.

1. Author submits a PR and picks up another ticket
2. Reviewer eventually checks it out, tries to understand what the PR body is trying to say and what to code is trying to do
3. Author sees comments, stashes changes, switches contexts, fixes code, resubmits
4. Reviewer switches contexts, clarifies, asks for more changes

Something that should take two person-hours drags into five spread across multiple days.

There’s got to be a better way!

Enter pair reviewing: the author and reviewer walk through the PR together in real time. The author explains the ticket, code, and test plan. Questions get answered immediately. Requested changes happen on the spot. No endless back-and-forth.

Like driver–navigator:

• In person: at a pairing station, in a conference room, or at a desk
• Remotely: collaboration tool or screen share

Now that we've gone through how you can effectively pair, let's dive further into its benefits.

🤔 The Why

At first glance, pairing seems like it would cut productivity in half. In practice, it’s usually the opposite.

With pairing, you constantly have a second set of eyes to:

• Catch mistakes early
• Validate implementations
• Deeply understand the code

Without pairing	With pairing
"Why the 🤬 doesn’t this work?!"	"Just restart the server"
"Nice PR. Can you do it in a completely different way?"	"Dang, this is super clean! High five!"
"Gotta wait for Bubba to get back from PTO to fix it"	"I got it"

Want to build a mentorship program without blowing the budget?

Want to foster camaraderie and collaboration?

Want to improve the quality and consistency of your code?

Pairing is the answer.

One final comment

Pairing for hours can feel exhausting at first (especially for us introverts). But with practice, it becomes second nature. And once you see the benefits, you might just find it’s your preferred way to code.