Pair Programming as a Management Tool
Two people on one computer isn't half the code, it's the fastest path to the right code.
- Difficulty
- Moderate
- Time to result
- ~weeks to results
- Steps
- 4
- Confidence
- 90%
A case for treating pair programming as the single most underutilized management tool in engineering. The bottleneck in software isn't keystrokes, it's finding the elegant solution, so two focused minds on one machine move faster toward value while raising learning, happiness, and knowledge transfer, and eliminating multitasking, at roughly a 20% code-volume cost.
Origin
Thawar ran the world's largest pair-programming office at Pivotal Labs and Extreme Labs, and paid out of his own pocket to put two people on one computer. Toby Lutke built early Shopify via pair programming. Thawar cites the underhand free-throw analogy (statistically better, looks dumb, so nobody does it) and Kahneman/Tversky via Michael Lewis's 'The Undoing Project.'
Core principles
- 01The throughput limiter is not hands-on-keyboard; it's discovering the good, elegant solution.
- 02Code is a liability that lives a long time, so fewer, more elegant lines beat volume.
- 03Forced co-presence removes multitasking: you can't check Twitter or Slack while being watched.
- 04Pairing raises happiness, knowledge transfer, and reduces silos, at a cost of ~20% of normal individual output.
- 05'Alone we're okay, but together we're a genius.'
How to run it
- 1
Put two people on one computer
Set up two keyboards, two mice, two monitors, one machine (or a remote tool like Tuple). Both engineers work the same problem together, talking through the design rather than racing to type.
Pro tip In-person, you can glance across the room and instantly see if a pair is working: two people intensely engaged means it's working; one leaning back means it's stuck, so walk over.
Watch out Expect people to feel like they're wasting time sitting beside someone. Like the underhand free throw, it looks and feels dumb even though it works.
- 2
Time-box to one hour and delete if you don't finish
Toby and CTO Cody set a timer and paired for one hour; if they hadn't finished the feature they deleted all the code, kept the tests, and started over, reasoning that inability to write it in an hour meant they were on the wrong design.
Pro tip He'd delete even if he was over by one minute. The elegant solution should be writable within the time box; going over is a design signal, not a reason to push through.
Watch out Deleting is emotionally hard because of the sunk-cost fallacy; you must fight the human instinct to keep code you've already written.
- 3
Rewrite immediately while the problem domain is fresh
In the strong version, if your pair was out sick and you wrote code solo, your pair deletes it the next day and you write it again together. The best time to rewrite is right after writing, when you finally understand the problem domain.
Pro tip The elegant, shorter solution appears only after pathfinding; start, delete, start again until you 'see the Matrix,' then write the real thing.
- 4
Apply it selectively, not universally
At contract-style shops (Extreme, Pivotal) where the spec was known, they paired 40 hours a week. At a pathfinding company like Shopify, pair 4-8 hours a week, or during incidents, reserving it for segments you're confident are correct and important.
Pro tip Pair heavily during incidents or when someone says 'I'm not really sure', jump on a call together to figure out what's going on.
Watch out For open-ended pathfinding where you don't yet know what to build, full-time pairing may not make sense; spend that time wayfinding instead.
In the wild
In early Shopify, Toby Lutke and his CTO Cody would pair-program with a one-hour timer. If the feature wasn't finished in that hour they deleted all the code, kept the tests, and restarted, on the theory that the right elegant solution should be writable in an hour. He'd start over even if only a minute over.
→ The discipline forced elegant designs and kept the codebase small; pair programming became foundational to how Shopify was built.
At his own startup, Thawar had candidates pair-program during trials and paid out of his own money to have two people on one computer, producing 'less than half the code.'
→ Pairing doubled as the hiring signal and the working method; the machine-learning hire he made this way is still at Shopify years later.
Common mistakes
Judging pairing by lines of code
The famous objection is 'two engineers on one computer, won't they write half as much code?' Thawar says maybe even less than that, but it misses the point: the limiter is finding the elegant solution, not typing speed. Optimizing for code volume is the wrong metric.
Refusing to delete because of sunk cost
Humans cling to code they've written. If you won't delete after pathfinding, you never land on the much better, shorter solution. The whole method depends on being willing to throw work away right after producing it.
Is it for you?
Best for
Engineering leaders who want faster delivery of correct, maintainable code plus high knowledge transfer, especially on important or tricky segments and during incidents.
Not ideal for
Pure pathfinding phases where the team doesn't yet know what to build, and contexts where the spec is trivial enough that solo work suffices.
From the transcript
“it is the most underutilized management tool in engineering Bar None”
“the throughput limiter is not Hands-On keyboard”
“if they did not finish the problem in one hour they would delete all the code and they would keep the tests and they would…”
“code lives a long time code is a liability”
From the episode
How Shopify builds a high-intensity culture
Farhan Thawar (VP and Head of Eng)