Muhammed's Blog

Code Review - How to Give Feedback Without Being a Jerk

The Art of Constructive Criticism That Actually Helps

3 min read

Code review can make you a better developer or make you hate your job. The difference? How feedback is delivered. Let’s talk about doing it right.

The Review That Made Me Quit

First job, first PR. The review: “This code is terrible. Rewrite everything.” No explanation. No guidance.

I quit three months later.

Code review builds or destroys team culture.

The Mindset Shift

Bad mindset: “I’m finding flaws to prove I’m smart.”

Good mindset: “I’m helping a teammate ship better code.”

Code review is about:

  • Catching bugs before production
  • Sharing knowledge
  • Maintaining quality
  • Teaching patterns
  • Building culture

If your review doesn’t make the codebase or the person better, you’re doing it wrong.

The Golden Rules

1. Critique Code, Not Person

❌ "You don't know how to write clean code"
✅ "This could be split into smaller functions"

❌ "Why would you do this? It's stupid"
✅ "This might cause issues with X. What if we tried Y?"

Attack ideas, not people.

2. Explain the “Why”

❌ "Change this"
✅ "This causes a memory leak—cleanup needed in useEffect's return"

❌ "Use const here"
✅ "const makes it clear this won't be reassigned, preventing bugs"

Teaching moments are gold.

3. Ask Questions, Don’t Demand

❌ "Change to async/await"
✅ "Have you considered async/await? Clearer error handling"

❌ "This is wrong"
✅ "I'm curious about this. Can you walk me through your thinking?"

Questions invite discussion. Commands shut it down.

4. Acknowledge Good Code

✅ "Nice edge case handling!"
✅ "Clever pagination solution"
✅ "Great test coverage"

People remember praise more than criticism.

5. Be Specific

❌ "This needs work"
✅ "Error handling could distinguish network errors from validation errors"

❌ "Improve performance"
✅ "This map() inside map() is O(n²). Lookup object makes it O(n)"

Vague feedback helps nobody.

The Review Process

Before starting: Am I in a good mood? Do I understand the context? Have time to review properly? If no to any, wait.

First pass: What’s it trying to do? Understand the problem and approach.

Second pass: Look for bugs, edge cases, performance, security, style issues.

Third pass: Nitpicks and suggestions—variable names, organization, refactors.

Categorize Feedback

[BLOCKER]   - Will break production
[CONCERN]   - Might cause issues
[SUGGESTION] - Consider this approach
[NITPICK]   - Minor style point
[PRAISE]    - Excellent work here
[QUESTION]  - Seeking clarification

Example: Blocking Issue

[BLOCKER] SQL injection vulnerability

// Current
db.query(`SELECT * FROM users WHERE id = ${userId}`);

// Fix
db.query('SELECT * FROM users WHERE id = ?', [userId]);

Example: Good Review

Thanks for this! Overall solid approach. A few suggestions:

[CONCERN] Line 45 throws if user is undefined
const userName = user.name;

Fix: const userName = user?.name ?? 'Anonymous';

[SUGGESTION] fetchData() is generic. fetchUserProfile() is clearer.

[QUESTION] Not handling loading state—intentional?

[NITPICK] Single quotes elsewhere, double here.

[PRAISE] Great edge case tests!

Common Scenarios

Junior’s first PR:

  • Don’t point out everything
  • Explain jargon
  • Focus on blocking issues only
  • Provide resources to learn

Different approach than yours:

  • Don’t insist your way is better
  • If it works, approve it
  • Ask questions, don’t demand

Code you don’t understand:

  • Ask for comments or refactors
  • Don’t reject it because you don’t get it

Security issue:

  • Be firm but educational
  • Don’t shame the author
  • Provide resources

Receiving Code Reviews

When you agree: ✅ “Good catch! Fixed in abc123.”

When you disagree: ✅ “I considered that, but went with this because X. Happy to discuss!”

When confused: ✅ “Could you elaborate? I don’t follow.”

Don’t: Get defensive. Ignore feedback. Dismiss suggestions.

Review Checklist

Functionality: Does it work? Edge cases? Error handling?

Code Quality: Focused functions? Clear names? No unnecessary complexity?

Security: No hardcoded secrets? Input validated? SQL injection prevented? XSS prevented?

Performance: Bottlenecks? Database optimized? No n+1 queries?

Testing: Tests added? Tests actually test? Edge cases covered?

Quick Tips

For reviewers:

  • Review within 24 hours
  • Start with big issues, then nitpicks
  • Use emoji occasionally (makes it friendlier)
  • If theirs works, approve it

For authors:

  • Keep PRs small (< 400 lines)
  • Self-review before requesting
  • Explain what and why in description
  • Respond to all comments

Code review builds culture. You can build fear or learning.

Choose learning.

Be kind. Be specific. Be helpful.

The code gets better. The team grows stronger. Everyone wins.