Member-only story
Why Everybody Hates Pair Programming
7 reasons why it has more downsides than upsides
My recent article on the merits of pair programming received a lot of criticism. It turns out most people hate pairing.
This surprised me because I’ve learned so much from it, second only to code reviews.
So I decided to dig into what’s wrong with pairing.
Why do developers hate pairing?
It prevents deep work
You can’t do deep work while someone is looking over your shoulder and telling you what to type.
I can’t disagree with this. “But what’s deep work?” you ask.
“Professional activity performed in a state of distraction-free concentration that push your cognitive capabilities to their limit. These efforts create new value, improve your skill, and are hard to replicate.” — Cal Newport, author of Deep Work: Rules for Focused Success in a Distracted World
Brainstorming solutions to problems in a group is not effective. It’s more efficient if individuals come to a meeting with ideas they’ve thought through in advance.
The same goes for coding. The hard part of software engineering is coming up with creative solutions given constraints (cost, technical debt, customer requirements, and so on). This is best done in solitude.
That said, pair programming can still be useful for implementation (aka writing code) after a solution has been thought out and agreed upon — particularly when it touches parts of the code base where you’re not an expert.
It’s not good for all developers
Anecdotally, most developers are introverts. Introverts prefer less stimulating environments, and pairing can be overstimulating.
This is a great argument for not pairing all the time.
But it doesn’t mean introverts hate socializing or dislike working in teams.
Especially in the age of “work from home forever,” pairing can provide some constrained social interaction when otherwise an introverted developer might spend their whole day not talking to anyone and staring at a screen. Not good for mental…
