[rasteau]

I think the author and many folks here have an unhelpful understanding of code reviews.

I suggest code reviews' primary purpose should not be to catch bugs or trivial style issues; automated tests and linters exist for those purposes.

Instead, code reviews should be primarily thought of as "human comprehensibility tests".

When we write code, we've may have spent a significant amount of time thinking about the problem. This puts us in a bad position to gauge how readily someone in the future can reason about our code in order to fix or modify it safely and easily. Code reviews are a mechanism for showing empathy to our future selves, which accumulates over time into a much more pleasant coding environment.

Relatedly, comments on a PR are ephemeral. A rule of thumb I use: if a reviewer asks a reasonable question -- something someone in the future might wonder about when I'm no longer around, I answer it by first improving the code.