Why Two People Work Together on the Hardest Problems
Pair programming has a bad reputation for being slow, and for most work, it is — two engineers producing the same output as one is a bad trade. We don't use it for most work.
We reserve it for the problems where the cost of a wrong turn is high: data migrations, anything touching billing, and the first pass at a new system's architecture. A second set of eyes in real time catches the assumption that a solo engineer won't notice they're making.
Measured per line of code, it's slower. Measured per production incident avoided, it's the cheapest hour we spend.
The value of pairing isn't extra typing speed, it's a second person questioning assumptions in real time instead of two weeks later in a code review. A solo engineer writing a data migration script has already convinced themselves the approach is correct before they start typing — that's how they decided to write it that way. A second engineer sitting alongside them hasn't made that same mental commitment, and asks the question the author stopped asking themselves an hour ago: what happens if this script fails halfway through a million rows.
Billing code gets the same treatment for a specific reason: the failure modes are asymmetric. A bug in a marketing page costs a bad first impression. A bug in billing logic can silently overcharge or undercharge thousands of customers before anyone notices, and the fix afterward involves refunds, support tickets, and an uncomfortable conversation with finance. The cost of catching that bug in the moment, with a second engineer watching the logic get written, is trivial next to the cost of catching it three billing cycles later.
Architecture decisions are the third category, and the reasoning is different — it's not about catching a bug, it's about catching a decision that's expensive to reverse. The first pass at how a new system's core objects relate to each other sets constraints that everything built afterward inherits. Pairing on that first pass means the decision gets stress-tested by two people's mental models instead of one, before six weeks of code gets built on top of it.
We're explicit that pairing isn't a code review substitute or a training exercise, even though it has side effects that look like both. It's a real-time decision-making tool for the specific moments where a wrong turn is expensive to notice later. Using it everywhere dilutes it into a scheduling burden. Using it nowhere means the expensive mistakes get caught the expensive way — in production, after the fact.
The honest accounting is that pairing costs an extra engineer-hour for every hour of pairing. What it buys back, on the problems we reserve it for, is the hours — sometimes weeks — that a serious production incident costs when nobody caught the wrong assumption in time.
