Pair programming, as a default practice, is a productivity hostage situation. Two developers. One keyboard. Zero flow state. All under the watchful gaze of an invisible Agile Coach whispering, “Trust the process…” and the wrathful scrutiny of your manager groaning, “why can’t they ship faster?”

You’re not coding — you’re live-commentating your own thought process while someone silently judges your brace placement. It’s like being on a bad date and solving a Rubik’s cube, but the cube throws exceptions and your date shares all of your worst qualities.

How Did We Get Here?

Somewhere between the fall of Waterfall and the rise of the Kanban post-it note dystopia, some very excited people decided that the best way to write software was to tie two developers together and make them work like a three-legged race team on Adderall.

Some called it “Extreme Programming.” Which is accurate, in the same way that base jumping while reading RFC docs is “extreme.” Others called it “Agile”, which is accurate, in the same way that a jellyfish has a strong internal structure.

Whatever the idea was, both sides agreed that the idea was noble: liberating the common dev from the tyranny of the bureaucracy — until seventeen middle-aged white dudes in fleece vests, each one a methodology nerd with their own thousand page manifestos, holed up in a ski resort, drank themselves halfway into a coma, and decided the solution to all engineering problems was vibes and velocity charts.

But in reality, these practices result in:

• Burnout

• Personal conflict within teams

• And the quiet exit of talented people, hoping for greener pastures elsewhere.

So… It’s Useless?

Mostly. But there’s one cursed relic of Agile that actually works — pair programming. But only if you use it carefully, and only in its natural habitat: onboarding ¹ .

What Pairing Actually Helps With

Pairing during onboarding is like being a tour guide in a haunted house. You’re not here to hold their hand — you’re here to say:

• “Don’t open that door, it leads to 2019’s payment system.”

• “This looks normal but was written by Steve, and Steve was going through a divorce.”

• “Yes, it’s in Kubernetes. No, we don’t know why.”

• “Again, Steve was going through a divorce, and Steve is the technical cofounder.”

• “You don’t want to cross Steve.”

You’re not just teaching code — you’re transmitting “cultural lore”, like a grizzled elder explaining why we don’t deploy on Fridays, and why the last person who touched dont_delete_please.php hasn’t been seen since ² . 

Why It Matters

It is functionally impossible for a new team member to be productive in an unfamiliar codebase — at least, not without help. And help, as it turns out, is rare. Why? Because no one is incentivized to give it.

Most devs are drowning in their own sprint tickets, and their performance is being judged on how many they ship — not how many newcomers they mentor. Taking the time to actually guide someone — to walk them through weird legacy logic, tribal knowledge, or undocumented system behavior — is a guaranteed way to slow yourself down. Which means it’s a career liability.

So What Happens Instead?

A new hire flails for weeks, trying to reverse-engineer the system by reading between the lines of Slack messages, confluence docs last updated in 2020, and code comments written like desperate journal entries. Meanwhile, the rest of the team assumes someone else is handling it. And no one is.

If we want onboarding to work — if we want new team members to stick around long enough to become productive — we need to build intentional, structured collaboration into the process.

That’s where pair programming — yes, that accursed artifact — actually shines.

Not as a default practice. Not as some Agile ritual whispered to Azathoth — mindless Lord of Chaos, blind idiot God of All Things, encircled by his flopping horde of dancers and lulled by the thin, monotonous piping of a demonic flute clutched in nameless paws. No. This is a time-boxed, measurable, justified investment in getting new hires ramped up the right way.

Not as a default practice. Not as some Agile ritual summoned with Post-it notes and the blood of a fallen sprint. No. This is a time-boxed, measurable, justified investment in getting new hires ramped up the right way.

It creates space for questions. It builds trust. And most importantly — it gives teams permission to slow down on purpose, in the name of long-term velocity. But, if we don’t bake it in, the only thing we’re onboarding is future churn, bad faith, lost dollars, and wasted time.

A week or two of intentional pairing — not micromanagement, just structured collaboration — can save you thousands in hiring costs. And maybe, perhaps…your own sanity and peace of mind.

Don’t be like Steve ³ .

What It Looks Like in Practice

Just assign two people to the ticket.

Final Thoughts

• Pair programming as religion? Heresy.

• Pair programming as onboarding? Divine.

Stop burning through new hires like they’re disposable coffee cups. Buckle up, sit next to them, and show them the secret tunnels. Then let them ride solo — like a real dev, free and caffeinated.

Pairing isn’t a productivity hack — it’s a retention strategy. Use it wisely.

1  That strange, mythical process where you hire a bright-eyed dev, throw them into a Kafkaesque repo full of dead services, and tell them to “hit the ground running.” (Corporate euphemism for “Good luck….”)

2  Occam’s Razor says it’s to avoid questioning by the authorities looking into a missing person. But it’s PHP. It could be anything

3  After the loss of his marriage and his business, Steve managed to recuperate sufficiently from late-stage alcoholism. He then went start a blockchain-based dog walking app. He raised $4.2 million and moved to Portugal. No one knows what the app does. Including Steve