Every question I get (when my code is reviewed) is a signal that code could be more self-explanatory, unless it is a complex algorithm itself, and that my — by now deep — exposure to the problem is keeping me misguided about what is and isn't "obvious" or "clear". A reviewer can take a step back and help ensure both them and I will be able to easily grasp the same code 3 or 24 months later.

Note that one of the best advice I got early in my career about doing a good code review is that you "just" need to ask good questions: the point is not for a reviewer to show how much smarter they are, but for both to develop a shared understanding and ensure code can be interpreted as quickly as possible.

So really, two professors' gut feel about what the reasons are and not backed by much.

Does everybody produce completely readable, tested code every time? Perhaps that's just "style" to you when it is "maintainability" to me?

My position is: do not ban (make illegal!) everything that has statistically significant risk for one's health (like smoking, alcohol, mountain climbing, spelunking, bike-riding, horse-riding, car racing, NFL...).

So no, I do not see why banning smoking altogether is a good idea (and no, I am not a smoker — I never was either). I can get behind increased health premiums or heavy taxation, banning smoking in communal spaces...

The emotional toll there is real, but this is exactly the moment when you expose the knowledge of that external dependency to the unbiased party that is the reviewer.

I like combining approvals to satisfy the urge for completion and closure, with a request for fast-follow refactor to better match the newly discovered model of interaction. (The worst code review experience I have seen is when a reviewer accepts it as-is and does a fast follow refactor themselves, depriving the author of the opportunity to learn and remain an expert in that area)

If you have these parties review each other's code, I agree that rarely brings much value.

I think the best way to understand our experience with reviews is to stop and say: in a few sentences, what do you expect out of a quality code review? (sounds like nothing in your case, but I am curious)

It is definitely very grunt-like for an LLM.

On your original claim, I have seen engineers put up 5x more PRs simply because they paid less attention to the quality or put less thought on each one of them.

I have seen people put up 5x more quality PRs too. But as long as they follow the good practice of doing a code review for every PR they put up (or 2 if you require 2 per PR), they got their stuff through quickly as well.

> your process ought to catch both of those well before the PR stage

We have multiple points where mistakes of any sort can be caught, and code review is one of them.

Yes, most architectural issues should be caught earlier, but some will only become evident in code: some by the dev themselves, others by reviewers.

This is only a problem if you mostly catch architecture issues at code review phase.

If anything, the poster here likely followed a rule to use the original, non-editorialized page title, and certainly the original page has not had the title set with intent to attract clicks by misrepresenting what it is.

> ...avoid stressors...

Most stress is caused by a conflict between our expectations/motivations and the reality (everyone else's).

There is just this minor point that their own agent simply doesn't use it and goes directly to lower level interfaces nobody else gets access to: exactly the thing DMA was designed to stop.