I've seen a lot of people talking about the practice of code review in a way that I consider unrealistic lately. So here are my thoughts on what code review is—and isn't—for: https://blog.glyph.im/2026/03/what-is-code-review-for.html
What Is Code Review For?

Code review is not for catching bugs.

@glyph have you read the naur paper I've recently been ranting about yet?
@chrisjrn I don’t think so?
@chrisjrn oh wait, “programming as theory building”. yes, I have muddled through a bit of it
@glyph you're making a lot of points that echo it: your "enculturation" idea in particular is very similar, but it's holding some unstated priors (e.g. that having multiple people understand the code is useful); Naur starts from the point of view of long-term maintenance, at which point, understanding seems essential
@chrisjrn it’s definitely ideologically aligned. I didn’t read it too deeply (partially because i have been just generally distracted, but also) because it echoed another one of my faves, https://blog.nelhage.com/post/computers-can-be-understood/ particularly “building mental models” .
Computers can be understood

Computers and computer systems are build up from deterministic, comprehensible, building blocks. Their operations and behaviors can be understood and reasoned about. I relate my personal beliefs and mindset on this point, and explore some manifestations and ramifications of this philosophy.

Made of Bugs

@glyph @chrisjrn love this article just from reading the first couple headings. Yes! Software can be understood! Computers are not magic!

I cite the Naur paper regularly and will add this one to my list.

@glyph @chrisjrn Might add "Do the easy thing first" to my mottos as a variant of "Check the obvious things first" which has saved me so many times and maybe the other wording will remind me to do it when I would otherwise fail to check the obvious thing!