[neo2006]

90% of a code review is not about finding THE BUG in the PR but asking questions and making the author find his own bugs or learning something from him. If you are performing a code review hunting for bugs you already lost your humility and think you are better then the PR author.

[AnimalMuppet]

Have you ever written some text, and re-read it, and it sounded just right, and had someone else read it, and they said "what does this mean"? Sometimes the words you write are sufficient to trigger in your own head the thoughts you've already had, but not enough to make someone else think those same thoughts.

Code can be like that, too. You write code, and it's enough to convince you that it does what you think it does. But someone else reading it can sometimes see the holes that you don't see.

Assuming that person X writes bug-free code is bad, whether X is "you", "me", or "that co-worker".

I don't have to be better than the PR author. I just have to be decently good, and be a different person. That's enough.

And of course I'm looking for bugs. That's the absolute first thing to look for!

Now, true, if I can help the author be able to see their own bugs (asking questions, maybe), then that's probably better than me just lecturing them. Teach them how to think so that they can see it themselves next time.

[neo2006]

I'm not saying that you will never find bugs in someone PRs I'm just saying it shouldn't be your first intention, your first intention should be to understand it and be convinced by it. Finding bugs will be a side effect of that. If you reading the code to execute it in your head and find all the weird combination that could trigger a core dump, you should probably check if the author wrote tests for those use cases instead and comment about missing tests. Genuine interest in others work can go a long way compared to imagining how would you solve it like the article author said.