# The Art of Code Review

Code review is one of the most valuable practices in software development. Done well, it catches bugs, spreads knowledge, and elevates the entire team. Done poorly, it becomes a bottleneck that breeds resentment. Here's what I've learned about doing it right.

The goal isn't to prove you're smart. I've seen reviewers leave dozens of nitpicky comments about spacing and naming conventions while completely missing a race condition. The best reviewers focus on what matters: correctness, security, maintainability, and whether the code actually solves the problem it's supposed to solve.

Before you write a single comment, understand the context. Read the ticket or issue. Look at the PR description. If you don't understand why a change was made, ask before assuming it's wrong. "Why did you choose this approach?" is more useful than "This is wrong."

Be specific and actionable. "This could be better" helps no one. "Consider extracting this into a separate function to improve testability" gives the author something concrete to work with. Even better: include a code snippet showing what you mean.

Distinguish between blocking issues and suggestions. Not everything needs to be fixed before merging. I use prefixes like "nit:" for minor style preferences, "suggestion:" for improvements that aren't required, and "blocker:" for things that must be addressed. This saves everyone time and reduces back-and-forth.

Praise good code. When someone writes an elegant solution or handles an edge case you hadn't considered, say so. Code review shouldn't only be about finding problems. Positive feedback reinforces good practices and makes the process less adversarial.

As an author, make your reviewer's job easier. Write clear PR descriptions explaining what changed and why. Keep PRs small and focused - reviewing 50 lines is easy, reviewing 500 is exhausting. If you know something looks weird but was intentional, add a comment explaining why before the reviewer has to ask.

Respond to feedback gracefully. Not every suggestion needs to be implemented, but every comment deserves acknowledgment. If you disagree, explain your reasoning. If you agree, make the change. If you're not sure, have a conversation.

Finally, remember that there's a human on the other side. Written feedback can come across harsher than intended. When in doubt, be kinder than necessary. A little empathy goes a long way in keeping code review productive and sustainable.