Those pesky pull request reviews

Here's a very simple solution: just don't do code reviews, at all. No company I've worked at had a meaningful code review process. In my current job, I get a few requests a day that say, "Could you just quickly approve this?" Code review is mindless rubber-stamping, a cargo cult of process that you've been told is important, for some reason, but it's hard to see why. I don't understand the purpose or context of 90% of the code I rubber-stamp. My coworkers don't understand the purpose or context of 90% of the code I write.

I can imagine an idyllic Valhalla of textbook software engineering practices where everyone diligently reviews PRs with utmost concentration, but that is not the reality I occupy.

What happened to good ol' classic periodic code reviews? Instead of either the inefficiencies of having everyone work together or having everyone get a review of every single incremental change to the code base, you let everyone work at maximum efficiency and then do periodic batch reviews and education sessions. Does this really sound so old fashioned that we have to instead invent new ways of being less efficient, lest one of my supposedly-adult coworkers even momentarily commits a mistake to the codebase?

I love this article, clearly you and your team have thought deeply about the process of code review and Pull Requests. By having strong principles you make sure you're not dominated by the process.

I actually don't think Pull Requests are "zero trust", in fact they work much better when they are high trust. They're a formal point for collecting comments and discussion in the workflow. I really value the feedback I get from my team in PRs, it makes my code better and doesn't slow me down because we are able to reach consensus quickly.

Plug: I'm working on a tool to make Pull Requests much better for teams who work on GitHub. If you're interested check out https://codeapprove.com or email me at sam at habosa dot com