The first time someone suggested we pair, I bristled. Two engineers, one keyboard — it sounded like a way to do half the work at twice the cost. I'd done my best learning alone, headphones on, and the idea of narrating my every move to a colleague felt like programming with a referee watching. I agreed because it would have been awkward not to. Then it quietly rewired how I think about the job.
Pairing isn't about typing faster, and it isn't really about catching bugs, though it does both. The value lives in everything that happens between the keystrokes — the small negotiations, the questions you'd never ask yourself, the assumptions that fall apart the moment you have to say them out loud.
You can't fake understanding out loud
Alone, I can convince myself I understand something I only half-grasp. I'll nod along to my own reasoning and move on. With a partner watching the screen, that shortcut closes. The moment they ask "wait, why does that work?" and I open my mouth to answer, I find out instantly whether I actually know. Half the time I don't, and we go and find out together.
That exposure is uncomfortable and enormously productive. Explaining is a form of thinking. When I have to articulate why I'm reaching for a particular approach — say, why I'd model this state machine one way rather than another — the explanation either holds up or reveals its own gaps. A lot of bad designs die in the sentence where you try to justify them aloud.
Two people, two mental models
Every developer carries a mental model of how the system works, and those models are always a little different. Pairing forces them into contact. My partner knows the deployment quirks I've ignored; I know the data layer they've avoided. Working side by side, we trade these maps constantly, often without naming it. By the end of a session, both of us understand the system better than either did alone.
This is also how juniors absorb the unspoken stuff. You can't write a wiki page for the hundred micro-decisions a senior makes per hour — which error to handle, when to look something up versus reason it out, how to read a stack trace at a glance. When a newer developer is reaching for a method, having someone there to say "let's check the docs — MDN's JavaScript docs are usually clearer than guessing" teaches a habit no tutorial conveys. They watch how you decide, not just what you decide.
It's a social skill in disguise
The hardest part of pairing isn't technical. It's learning to share control gracefully — to let go of the keyboard, to suggest without seizing, to sit with someone's slower approach when yours would be faster but they'd learn less. Done well, it's a small daily practice in patience and clear communication, which happen to be the exact skills that separate a decent engineer from one people actually want on their team.
I won't pretend it's always pleasant. Pairing is tiring in a way solo work isn't; the constant low-level communication drains a different battery. I don't do it all day, and I don't think anyone should. But for gnarly problems, for onboarding, for the parts of the codebase only one person understands, an hour of pairing is worth an afternoon of solitary grinding.
What it taught me, more than any technique, is that software is a conversation. The code is just where the conversation gets written down. Pairing makes that conversation explicit for a couple of hours, and once you've felt it, you start hearing it everywhere — in reviews, in design docs, in the quiet collaboration that good teams run on.
