Comment by pessimizer

> in real code reviews bugs and errors are identified by reviewers all the time.

I think that this would be better directed at the person who posted "no one ever finds bugs during code review" rather than at the person who said that just re-reading code is (obviously) not an effective way of debugging, and is better thought of as a time to make code clear enough that bugs will be more apparent or less likely to be introduced by later authors.

> I’m not a fan of these blanket declarations that code review isn’t about reviewing code.

Using a shovel to dig a hole isn't about using a shovel, it's about digging a hole. Reviewing code is a necessary prerequisite to finding code that will be hard to maintain (and finding any number of other things, and knowledge transfer, and getting acquainted with coworkers' coding styles and domains, etc.) It is not a purpose in itself, but a tool.

> code review isn’t about one thing.

But you just said that code review is about reviewing code, and explicitly not about "some other thing" in the beginning of the sentence, right before listing two other things that code review could be about, and then insisting that it could be about many other things. The author is saying that it is primarily about one thing, likely because in their opinion it is most effective at that one thing, and that one thing goes a long way into solving other issues.

It isn't like they said "ignore bugs during code review, never learn anything from it."

I agree with the OP. Code reviews are finishing steps where things are polished, and polished code should be correct code, but more importantly intelligible code. If your code is clear, the mistakes will be obvious to more people than if your code is not readable. To make it simple: you've written something and it feels done, now you want someone to read it to see if it makes sense to them. No different than any other type of writing.