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:
TypeExampleTone

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

QualityDescription

TimelyReview within 4 hours, not 3 days
SpecificPoint to exact lines, not "this is wrong somewhere"
EducationalExplain WHY, not just "change this"
EmpatheticRemember someone spent hours writing this code
ActionableSuggest a solution, don't just identify the problem