Effective Code Reviews: How to review without being hated

Code Review (CR) is the single most effective tool for knowledge sharing. But in many teams, it is a source of anxiety.

• The Nitpicker: Comments on indentation but ignores the race condition.
• The Ghost: Approves without reading ("LGTM").
• The Gatekeeper: Blocks the PR for days because "I wouldn't have done it this way."

Here is how to review like a Senior Engineer.

Here is what we'll cover:

1. The Hierarchy of Feedback: What matters vs. what doesn't.
2. Tone: Asking vs. Telling.
3. Size: Why 500-line PRs are unreviewable.
4. Speed: The 24-hour rule.

1. The Hierarchy of Feedback

Don't treat all issues equally. If you leave 50 comments about variable names and 0 comments about the architecture, you failed.

Prioritize in this order:

1. Correctness: Does it work? Is there a bug? (Critical).
2. Security: Is there an injection vulnerability? (Critical).
3. Readability: Can I understand this in 6 months? (Important).
4. Architecture: Is this the right pattern? (Important).
5. Style: Indentation, variable casing. (Trivial - USE A LINTER).

Mentor Tip: Never comment on something a Linter can catch. Automate the trivial stuff so you can focus on the logic.

2. Tone: Asking vs. Telling

Text is cold. "Change this" sounds aggressive. Use the Socratic Method. Ask questions.

• Bad: "Rename this variable to userId." (Command).

• Good: "What do you think about calling this userId to match the schema?" (Suggestion).

• Bad: "This loop is slow."

• Good: "I'm worried this might be O(n^2). Did you consider using a Map here?"

Prefixes: Use conventional comments to signal intent:

• [NIT]: Nitpick. feel free to ignore.
• [BLOCKER]: I cannot approve until this is fixed.
• [QUESTION]: Just asking for my own learning.

3. The 400-Line Limit

There is a famous law:

• 10 lines of code: 10 issues found.
• 500 lines of code: "Looks good to me."

The human brain cannot hold context for massive changes. If your PR is > 400 lines, split it up.

• PR 1: Backend Model changes.
• PR 2: API Endpoints.
• PR 3: Frontend UI.

Reviewing 3 small PRs is faster than reviewing 1 giant monster.

4. Speed: The 24-Hour Rule

Unreviewed code is Inventory. It is waste. If a PR sits for 3 days, it rots. The author forgets the context. Merge conflicts appear.

The Rule: Review code within 24 hours. Treat reviews as a "High Priority Interrupt." Unblocking your teammate is more valuable than writing your own code.

Summary

1. Automate Style. (Prettier/ESLint).
2. Be Kind. Ask questions.
3. Keep it Small. Split PRs.
4. Be Fast. Unblock your team.