Approach to Code Reviews

I think of code review as both a quality gate and a teaching channel — my rule is that every comment should either prevent a production problem or teach the author something reusable, and if it does neither, it is probably bikeshedding. When I review I label severity explicitly — blocking versus suggestion — and I explain the why, not just the what. For example, pointing out that a shared data structure needs ConcurrentHashMap because the service method is called from multiple request threads simultaneously gives the author a mental model they can apply everywhere, not just a one-off correction.

When I am the author I answer every comment, even acknowledging nits, because ghosting wastes reviewer effort and erodes the trust that makes future reviews faster. A reviewer once caught me allocating a new RestTemplate inside a hot loop, which would have exhausted our connection pool at production traffic levels. I fixed it, added a regression test, and shared the anti-pattern in a team sync so everyone could scan their own services.

That story captures both sides: specific, kind review with an explicit severity label on one hand, and humble, responsive authorship on the other. The tip I always close with is this — if your review comment cannot articulate the production consequence of ignoring it, reconsider whether the comment is worth leaving. The best code reviews teach patterns, not just catch bugs.