All Articles
Career7 min read

The Art of Code Review: How to Give and Receive Feedback

Code reviews are for sharing knowledge, not finding bugs. Best practices for reviewing PRs without being a jerk.

T

TechGyanic

November 15, 2025

The Art of Code Review: How to Give and Receive Feedback

A bad code review culture destroys teams. "Why did you do this?" "Fix this." "Bad style." A good culture accelerates learning. Here's how to do it right.

For Reviewers (Giving Feedback)

1. Be Kind and Constructive

Bad: "This function is too big. Break it up." Good: "This function handles three different tasks (validation, parsing, saving). Extracting the validation logic might make it easier to test. What do you think?"

2. Focus on "Why", Not "What"

Don't just point out errors. Explain the reasoning. "Using forEach with await doesn't wait for the promises. Use for...of or Promise.all so we don't miss errors."

3. Distinguish Blocking vs Non-Blocking

Label your comments:

  • [Nitpick]: Variable naming, spacing. Optional fix.
  • [Question]: Asking for clarification.
  • [Suggestion]: Better way to do it, but current way works.
  • [Request Changes]: Actual bugs or security issues.

4. Catch Architecture, Not Syntax

Let the linter/CI catch missing semicolons. You focus on:

  • Edge cases
  • security vulnerabilities
  • Performance bottlenecks
  • Readability

For Authors (Receiving Feedback)

1. Separate Ego from Code

Use "The code" instead of "My code." When someone critiques the code, they aren't critiquing you. You are not your code.

2. Provide Context

A PR description with "Fixed bugs" is useless. Include:

  • Screenshots/Videos
  • Link to ticket
  • Testing steps
  • Why you chose this approach

3. It's Okay to Push Back

If you disagree, explain why respectfully. "I considered extracting a component, but felt it was premature optimization since we only use it here. Happy to change it if you foresee reuse soon."

The "LGTM" Problem

Don't just comment "LGTM" (Looks Good To Me) without reading. If you don't understand the code, ask questions or say "I only reviewed the frontend part."

Checklist for a Good Review

  1. Functionality: Does it do what the user needs?
  2. Complexity: Is it simpler than it looks?
  3. Tests: Are there tests? Do they cover edge cases?
  4. Naming: Do variables explain themselves?
  5. Comments: Do they explain "Why"?

Code review is the highest leverage activity you do. It improves code quality AND team knowledge simultaneously.

code-reviewcollaborationcareerbest-practicessoft-skills
Share this article
T

Written by

TechGyanic

Sharing insights on technology, software architecture, and development best practices.