What Good Code Review Actually Looks Like

Code review isn't about catching bugs (tests do that). It's about knowledge sharing, consistency, and catching the things automation can't.

Code review gets a bad reputation when it turns into a bottleneck or a vehicle for ego. Done well, it's one of the highest-leverage activities an engineering team can invest in. It catches architectural issues before they become expensive, spreads knowledge across the team, and keeps the codebase consistent.

What to look for

• Does this code do what the ticket says it should do?
• Could I understand this code six months from now without the author explaining it?
• Are there edge cases that aren't handled?
• Is the error handling appropriate (not too much, not too little)?
• Does the approach match our existing patterns, or is there a good reason to deviate?

What NOT to waste time on

Formatting, import order, semicolons, bracket placement. Automate all of this with Prettier and ESLint. If your team is arguing about formatting in code review, you need better tooling, not better reviews.

How to give feedback

Be specific. "This is confusing" is useless. "I wasn't sure what this function returns when the user has no orders - could we add a comment or rename it?" is actionable. Ask questions instead of making demands. "Why did you choose X over Y?" opens a conversation. "Use Y" shuts it down.

Keep it moving

Review turnaround should be under 24 hours. A PR that sits for three days waiting for review kills the author's momentum and context. If you can't do a thorough review, do a quick first pass and flag anything blocking so the author can address it while waiting for the full review.

Ben Arledge

CEO & CTO, CloudOwl