Code reviews are one of the most underrated signals in engineering. Not someone's code — their comments on other people's code.
Because here's the thing: anyone can write code. But the way you review it? That reveals how you actually think.
Here are eight code review comments that are green flags so strong they're practically waving themselves off the screen.
1. "Let's add a test for the edge case."
Most developers think in happy paths. User enters valid data, everything works, ship it! But the developers worth hiring think about what happens when someone enters negative numbers, empty strings, or decides to upload a 50GB file.
These are the people who think beyond "does it work?" to "what could possibly go wrong?"
Without this person on your team? Your app crashes at 2 AM on a Saturday because someone in Australia entered a negative quantity. And now you're debugging in your pajamas.
2. "This could be more readable."
This comment shows someone who understands that code is read way more often than it's written.
They're not chasing clever one-liners that look like hieroglyphics. They know that clever code isn't good code — maintainable code is good code. And they're thinking about the next developer who'll read it, which is usually themselves three months later.
Without this mindset? You spend three hours debugging code you wrote last month, squinting at variable names like x2 and tmp_val_final_v3.
3. "Have we considered performance here?"
This is the developer thinking about scale before it becomes a problem.
They see a nested loop and their spidey-sense starts tingling. Sure, this works fine with 10 records — but what about 10,000? O(n²) looks totally fine until n equals 10,000 and suddenly your users are staring at loading spinners like they're watching paint dry.
Without this mindset? Your database melts down on Black Friday while your CEO breathes down your neck about lost revenue.
4. "Nice! This is much cleaner than before."
This one might seem out of place on a technical list — but hear me out.
Code review isn't just about catching bugs. It's about people. Someone who gives positive feedback understands that. They're building trust. They're making teammates want to write good code, not dread every pull request like a trip to the principal's office.
Without this? Code reviews turn into tense, negative experiences. Morale tanks. People get defensive. Team culture slowly turns toxic.
The best engineers give just as much positive feedback as constructive criticism.
5. "What if this service is down?"
This person isn't thinking about just their function — they're thinking about the entire system.
What happens when the payment API times out? What if the database connection drops? What if that third-party service decides to have a bad day? This is the defensive programming mindset, and it's what separates people who build brittle systems from people who build resilient ones.
Without it? One API timeout brings down your entire application like a house of cards. When one service sneezes, the whole system catches pneumonia.
6. "Could we extract this into a helper function?"
This developer has a sixth sense for duplication — and they spot it before it spreads.
They live by DRY (Don't Repeat Yourself), not as an academic principle, but as something that saves hours of maintenance. Here's what happens without this thinking: you write the same logic once, copy-paste it when you need it again, and again, and again. Now it lives in 12 different places.
When you need to update it? You get 11 out of 12. And that one you missed? That's the one that causes the production bug.
7. "Let me suggest an alternative approach."
Notice the language. Not "you should do this." Not "this is wrong." But "let me suggest."
This is collaborative, not dictatorial. They're offering solutions, not just pointing out problems — and doing it in a way that respects the original author's thinking.
Without this collaborative spirit? Code reviews feel like criticism sessions. Egos get bruised. Your team stops communicating effectively. The best code reviews feel like a conversation between peers, not a lecture from a know-it-all.
8. "Is this backward compatible?"
This question shows someone thinking long-term — about existing users, existing integrations, existing systems.
They understand that breaking changes don't just mean updating your code. They mean pain for everyone using your API. Urgent updates. Angry customers. They're choosing sustainable evolution over quick wins.
Ignoring this? Your deployment breaks 50 client integrations at once. Your support team drowns in tickets. And you're writing an apology email explaining why everyone's app stopped working.
Why Do These Comments Matter So Much?
Because they reveal engineering maturity that goes way beyond syntax and algorithms. They show how someone thinks, not just what they know. And they indicate someone who makes the entire team better — not just someone who writes good code themselves.
Anyone can learn a programming language. But awareness of systems, people, edge cases, and long-term consequences? That's what you actually want on your team.
So Here's the Real Question
Do your code reviews show these qualities?
If you want to level up as a developer, start here. Start leaving better comments. Think beyond your own code. The next time you review a pull request, don't just look for bugs — consider edge cases, ask about failure modes, think about performance, and yes, throw in some positive feedback too.
Great code reviews don't just improve code. They improve engineers.
Note: This article was written with AI assistance to help structure and articulate 25+ years of debugging experience. All examples, insights, and methodologies are from real-world experience.
What code review comments impress you? Drop them in the comments — I'd love to hear what green flags you look for.
Top comments (0)