How do you approach code reviews — both giving and receiving feedback?

My Code Review Philosophy

Giving Reviews

The Nit → Nits Ratio I aim for 80% substantive feedback, 20% nits. If my review is only nits, I'm not adding value.

Framework for Feedback:

Type	Example	Tone
Question	"What happens if userId is null?"	Curious, not accusatory
Suggestion	"Consider using a Map instead of an object lookup for O(1)"	Helpful, not demanding
Praise	"Great error handling here, especially the retry logic"	Genuine, specific
Blocker	"This query has N+1, will cause performance issues at scale"	Clear, with evidence

Receiving Reviews

When someone suggests a change to my code:

1. Don't take it personally — They're reviewing the code, not me
2. Ask for clarification if I don't understand the suggestion
3. Push back with data if I disagree — "I chose X because of Y benchmark"
4. Thank them for catching issues I missed

Real Example

In a PR review, a junior developer pointed out my function had a race condition:

• My reaction: "Good catch! I didn't consider concurrent access here."
• I asked them to explain their suggested fix (they used a mutex pattern)
• I learned something new from a junior developer
• They felt valued and confident

What Makes a Great Reviewer

Quality	Description
Timely	Review within 4 hours, not 3 days
Specific	Point to exact lines, not "this is wrong somewhere"
Educational	Explain WHY, not just "change this"
Empathetic	Remember someone spent hours writing this code
Actionable	Suggest a solution, don't just identify the problem