I think it's time to discuss the efficacy of Pull Request Reviews as a way to ensure code quality and shared understanding on software teams. Here's a little thread on some of the experiences I've had in my career, why I think this matters, and what we can do about it.

First though, a bit on my background.

In the early days of my career, most teams used cvs or svn. A "code review" was literally a scheduled meeting in a physical room with a 1024x768 projector. Everyone nitpicked your code, it was terrifying, and it took at most two hours.

Now we use git. git's easy merges enabled GitHub to build a sophisticated Pull Request Review tool & workflow. People love it. Most teams now require an approved review for every PR. Everyone nitpicks your code, it's terrifying, and it takes anywhere from 4 hours to 3 years.

But in-between the death of Projector Reviews and the birth of GitHub's Approve button, there was a beautiful interregnum. My teams leaned into Extreme Programming's collective ownership: pairing, testing, storming & norming. No code review to dread. Instant, empathetic feedback.

To say that serving on teams that strived to thoughtfully practice agile engineering methods transformed my career would be an understatement. I learned more in 6 months in 2010 than I had in the previous 6 years—or, frankly, the most recent 6 years.

My career also took off.

In 2010, the arguments against collective ownership—particularly pairing—were that it was wasteful (2 people at one computer!), emotionally exhausting, and unsuited for introverts or folks who got more done by themselves with headphones on.

Objections to pairing usually boiled down to three underlying issues: (1) a lack of trust that the team will get enough done, (2) a lack of safety to have one's own ignorance on display in real-time with a pair, and (3) the inconvenience of syncing schedules, being social, etc.

[2 of those issues are deep-seated root cause problems that should be fixed! Management & teams should build trust. People should be made to feel safe. And if a practice like pairing exposes them, that's good!

The 3rd issue—accessibility & inconvenience—it's a legit drawback.]

[Another problem with pairing was that most people never got a chance to try it. And that's not some No True Scotsman argument. I mean most people were literally seeing over-the-shoulder troubleshooting and hearing it called pairing. See "ping-pong pairing" for a better example.]

So here we are in 2021 and there's no debate: GitHub PR reviews have won the day. But I don't hear much talk about collective code ownership. And I don't see intentional pair-programming very often (lately, "pairing" has come to mean screen sharing with one passive participant).

To wit, I've seen three approaches to code review which exhibit this matrix of traits:

Projector Reviews: low-comfort, low-information, low-empathy

Pair Programming: low-comfort, high-information, high-empathy

Pull Request Reviews: high-comfort, high-information, low-empathy

So if you ask: are Pull Request Reviews better than Projector Reviews? Absolutely. Almost anything would be. Not doing anything at all is often better, on-net.

Are PRs better than Pair Programming? It depends. What do you value more? Comfort & autonomy or empathy & cohesion?

Why am I sharing this now? Because I just had my 4th conversation *this month* with different developers at different companies about the toll that an individual Pull Request Review or its broader process has had on them emotionally, or on a relationship, or on team-wide trust.

Each time, I tried saying "well in the good old days of 7 years ago, we just paired often and prioritized normalization and trust-building, so why not do that?"

But "pair more" isn't a solution when the team mandates that all code must also be approved via a Pull Request Review.

Evaluating the efficacy of Pull Request Reviews is hard. The experience is asymmetrical:

They're great for me! I can nitpick others. Cite sources to deflect critique. Appeal to my authority or experience.

Less experienced person who feels like an imposter? Different experience.

So if I were *designing* a way to erode safety & trust, I'd choose an async, text-based process in which any one person can derail others' work by nitpicking it.

Show off knowledge. Re-fight a lost battle. Assert authority. Defend turf. Cover up insecurity. Call it code review.

The reason I personally care so much about this topic is that—despite all my bluster online—I'm a vain coward who's incredibly insecure and craves the validation of everyone at all times.

Any process that empowers "That Person" is my personal kryptonite https://twitter.com/searls/status/1369304973956235267?s=20

(Come to think of it, the way most teams conduct code reviews reminds me a lot of unmoderated Q & A session following a conference talk. At best, mildly elucidative; at worst, deeply painful.)

But if you love the PR Reviews, or you're not interested in pairing, I get it. Not All Pull Request Reviews are bad. Some teams seem just fine with them.

But I wouldn't be surprised if someone on your team is carrying some pent up fear and shame about them and isn't telling you.

And in my book, individuals feeling safe & teams building trust are orders of magnitude more important than catering to my own or anyone else's personal comfort. Whether that's coding solo, or in the dark, or with music. Or to keep their programming ability from being scrutinized

While I wish everyone had the kind of pair programming experience I had, I'd never think less of anyone if they NEVER paired.

What I'm saying here is it's the duty of every team to build trust, normalize on approach, and foster collective ownership. PR Reviews aren't cutting it.