Claudio Lassala's Blog

Code reviews are one of my favorite practices in software development, but I’ve also seen how easily they can go wrong. Too often, a review turns into nitpicking or a power play. At their best, though, reviews help us learn together, improve the code, and strengthen the team. That’s why I approach them with two guiding principles:

1. Do no harm.
2. Do good.

It’s About People First

When you’re reviewing code, you’re not just looking at lines of C#, JavaScript, or Python; you’re engaging with a teammate. That means understanding their background, their skill level, and their perspective. A code review should never be about proving who’s smarter. It’s an opportunity to connect, coach, and learn from each other.

Sometimes that even means meeting the team where they are. If the most “clever” version of the code makes it harder for others to understand and maintain, then it’s not the best solution for the team.

Start With the Tough Stuff

Whenever I join a new project, I ask: Show me the nastiest part of the codebase. The invoicing module, the county tax calculator, that 5,000-line class nobody dares touch; those are goldmines for learning. By starting with the hardest, messiest code, I get a baseline for where things stand and a chance to demonstrate how to make progress, one small refactor at a time.

The key is to move iteratively. Extract a variable. Rename something for clarity. Pull a repeated block into its own method. And document your thought process along the way so others can see not just the what, but the why.

Separate the What from the How

One of the biggest problems I see in messy code is repetition: copy-paste blocks, duplicated strings, or long if/else chains. The fix often comes down to a simple principle: separate the what from the how.

Instead of repeating code, define what needs to be done, and then determine how to process them in one place. The result is cleaner, easier to read, and much easier to change later. See an example here.

Teach Along the Way

Code review isn’t just about cleaning up syntax or catching bugs; it’s a chance to teach and learn. Show others how to use refactoring tools in the IDE. Explain why a ternary operator works better in one place but not in another. Share the design patterns that help avoid endless if/else chains or god objects. The point is not to impose your style, but to coach the team forward.

And don’t forget tests. Bad tests can be just as harmful as bad code. Copy-pasted test cases with meaningless differences give a false sense of security. Instead, write tests that clearly express the intent and help others understand why a particular case matters.

Documenting Refactorings

When I clean up code, I document the journey. Sometimes that’s as simple as taking diffs and screenshots with arrows explaining changes. Other times, I’ll create a short screen-capture video. This is a way of leaving a learning trail for the team so they can follow the thinking, not just the result.

Closing Thoughts

Clean code isn’t about perfection. It’s about making things a little better, every time you touch them, while respecting the people who will read, use, and extend that code after you.

So remember:

• Rule #1: Do no harm. Don’t use reviews to show off or put others down.
• Rule #2: Do good. Use reviews to coach, to share, and to learn together.

I’ll be the first to admit: I don’t always write great code. None of us does. But if we approach reviews with humility and a mindset of improvement, then every messy line is an opportunity to grow, both for the code and for the team behind it.

Here’s a recording of my “Code Review: I Mean No Harm!” from years ago, which includes many examples from past code reviews.