The Difference between Good and Bad Code Reviewers
Bad code reviewers use grep... well, good code reviewers use grep, but they are good code reviewers!
You are probably not familiar with this French skit about the difference between a good hunter and a bad hunter: "The bad hunter, he sees something, he shoots... well, the good hunter sees something, he shoots, but it's not the same!". This skit inspired this post because the same idea applies to code reviewers. Let me explain!
Both good and bad code reviewers use grep during their reviews. Grep is an amazing tool and a must-have when reviewing code, no doubt about that. But the key difference lies in how they use grep.
The Bad Code Reviewer
A bad code reviewer is looking for shortcuts, using grep to find low hanging fruits, quick wins, "mad hackz". They want quick wins, maybe even a CVE and barely look at the actual code. Or worst, their whole review is based on triaging the output of a few grep commands (or any similar tools).
That’s the equivalent of running web scanners on an application and complaining that you are not finding good things.
As a result, they don’t find good bugs, they don’t get better and quickly get discouraged: "Code review isn’t my thing", "Code review is boring". If you think this is you, don't worry, I have been there too.
The Good Code Reviewer
On the other hand, good code reviewers use grep to speed up their review, not to guide it. They may use grep to get familiar with the organisation of the codebase, or to see if a pattern they find is present in multiple places in the codebase. Basically, they are in charge of the review and grep is a tool they rely on for help or to scale their efforts. Not the other way around.
They don’t rely on grep to do the heavy lifting. They focus on thoroughly reading the code, rather than seeking shortcuts or quick hacks. They are understanding the codebase, looking for small discrepancies, tiny weaknesses in the code, looking for unexpected behaviours in the way developers do things, filter values, prevent vulnerabilities. Once they are familiar enough with the codebase, they usually start finding bugs - good bugs. Unknown unknowns, bugs that you would never thought of looking for, let alone using grep. Bugs that grep will not find, bugs that SAST will not find, bugs that will stay undiscovered for a while unless they decide to share them.
Improving
If you find yourself relying heavily on grep for quick wins, it might be time to reassess your approach. Ask yourself: Are you letting grep guide your review, or are you using it to complement a thorough, manual inspection of the code? By shifting your mindset and using grep as a tool rather than a crutch, you'll start to uncover the deeper, more complex bugs that truly make a difference.
