Have you ever had that colleague who performs code reviews as if they were in a courtroom, ready to sentence your pull request (PR) to life imprisonment without the right to appeal?

 

You write solid code that you’ve refined and tested, push the PR expecting relevant technical feedback, and receive disapproving comments like:

  • “This if statement could be on a single line. It would be more elegant.”

  • “The order of imports should be different, even if it works the same.”

  • “I’m not sure, but this indentation doesn’t seem ideal to me.”

And then the entire team, without clear guidelines, ends up adopting the approach: “Just do something and wait to see if they approve it or come up with another random detail to judge.”

 

What if code review wasn’t just about code?

It’s about people, about helping each other grow as developers, improving code quality together and, above all, avoiding that atmosphere where someone is right and someone else is wrong.

 

Well-done code review isn’t one that only points out what’s wrong, but one that explains why and suggests how to improve.

 

Why do we perform code reviews?

Reviewing code is one of the most valuable practices for any development team – here's why:

  • Improves software quality

    Two pairs of eyes see better than one. Reviewing allows detection of bugs, logic flaws, pattern violations and opportunities for improvement before the code reaches production.

  • Spreads knowledge

    When reviewing, developers learn about parts of the system they might never have touched otherwise. This reduces points of failure and better distributes the technical understanding of the project.

  • Develops people

    Those who review teach, and those whose code is reviewed learn. This is valid both to those who are just starting and to those who are experienced but have just joined the team.

  • Prevents unnecessary code

    Reviews prevent duplicate functionalities from being created – something very common when knowledge is compartmentalised or poorly documented.

  • Strengthens team spirit

    When code review is done with empathy, it becomes a meeting point between experience, creativity and learning. And everyone stands to win.

 

How to perform code reviews that actually help rather than demotivate

  • Explain the reason for your feedback

    Saying "this is wrong" doesn’t help. It's much more useful and respectful to say: “This method could cause a performance issue because of X. How about this alternative?”.

  • Make the PR a discussion, not a verdict

    Sometimes the developer has a good reason for doing it that way. Instead of rejecting instantly, question and debate. You might end up learning something too.

  • Remember: the goal is to learn, not prove a point

    If someone more junior makes a mistake, this is the perfect moment to teach and share knowledge. Revising with empathy helps much more than simply writing a red “X”.

  • Don’t just criticise – praise too

    If you see clean code, a smart solution, or a well-executed refactor, say so. Recognition is part of learning, and positive feedback is feedback too.

  • The code belongs to the team, not a single developer

    The ultimate goal is a well-built system. It doesn’t matter who won the argument, but rather that the team delivers something with quality, clarity and performance.

 

What about the famous Looks Good To Me (LGTM)?

There’s also the other extreme: code reviews that are too quick and superficial. If you have spent two weeks writing a PR and the review comes back in 30 seconds with a LGTM, something’s wrong.

 

A review that’s too quick might indicate that:

  • The reviewer didn’t actually read the code and just wants to get rid of the task.

  • The team lacks a well-defined quality standard.

  • The code might contain bugs or questionable decisions that no one noticed.

 

So, approving without a real review is just as bad as rejecting without explanation.

 

The ideal approach? Finding a balance between constructive and productive feedback without becoming a bottleneck in the workflow.

 

Real-life examples: saving commits (and sprints)

1) Duplicate module saved in time

Once a developer created an entire module to handle a specific type of error in report generation. Everything was well done, tested, polished. But... there was already an ErrorHandler that did exactly that – simply with another name and in a less obvious namespace.

 

The review avoided an unnecessary commit, reduced complexity and even served to explain to the new colleague: “We already have a pattern for this here. When dealing with integration errors, take a look at this handler first.”

 

The result? Clean code, sprint delivered on time, and a new person on the team who now knows the system better.

 

2) Adapters and lack of communication

On another occasion, during a framework upgrade, several dependencies needed to be maintained due to the age of the code. Without clarity on who did what, some developers (myself included) created adapters to facilitate the use of repeated data between interrelated dependencies.

 

Due to lack of communication and deadline pressure, these adapters remained – even though there were more updated and cleaner versions. No one said anything in the pull requests. The result? Unnecessary code, no real improvement, and the team missed the chance to grow technically.

 

3) Cache, integrity and context

In a high-availability system, I needed to manage a memory-cached log buffer process that later dumped to the database. It was critical for performance.

 

I implemented a hash to ensure data integrity. In the review, the Tech Lead pointed out an important problem: the client's system wouldn't handle such large objects in memory. The kind of insight that only someone with experience and context of the environment could have.

 

This exchange not only improved the system but also gave me a much deeper understanding of the client's non-obvious constraints.

 

Questions worth gold during a code review

Here are some guiding questions that can help in this process:

  • Will these changes improve quality now and in the future?

  • Is the code well designed and easy to maintain?

  • Is it tested and does it do everything it's supposed to do?

  • Could it introduce bugs, security breaches or performance issues?

  • Is it aligned with the standards and decisions already adopted by the team?

 

Conclusion

If code review were a game, it wouldn't be ‘who makes the most mistakes’ or ‘who catches the most bugs’, but rather a high-performance ‘co-op’, where every pull request becomes a chance to:

  • Collaborate instead of compete.

  • Learn instead of just pointing out mistakes.

  • Share context instead of isolating knowledge.

  • Deliver solid code without losing joy (and sense of humour!).

At the end of the day, the best feedback is that which makes us recognise that the final product has really improved and that we’ve learned something new.

 

So, the next time you're reviewing a PR, remember: you're not wearing a suit in court, you're wearing a cap in a code review blitz. Take a deep breath, empathise, and let's play this team game until everyone wins!

 

Want to learn more about code reviews with a human touch?

I recommend reading:
Share this article