Mastering the Code Review Cycle

A developer’s guide to streamlined and impactful reviews

Jul 30, 2025

👋 Hi beloved Optimist Engineer, Marcos here!

📣 Before starting: This is the last edition until September.

I’m taking August to get rest and recharge batteries, as I mentioned in the About Page, so you should not expect any new newsletter issue during August.

Hope you have some time to rest as well.

Now, let’s go for the last ride of the summer.

I come once again with a special guest, Alberto Carrasco Montenegro, and I let Alberto introduce himself.

Alberto Carrasco Montenegro is a Software Engineer who has been working in the industry for around 20 years already. Always dedicated to software development tasks, he enjoys being part of passionate teams with a taste for quality and innovation.
He has been exposed to very different corporate cultures (national/multinational, big/small, traditional/startup, office/remote...) and sharpened his skills working on a variety of fields (Intelligent Transportation Systems, Digital Employee Experience, AI-powered Systems, etc.). Out of the office, he is keen on sports (football, tennis) and music concerts.

Give it up for the one and only Alber 🙂

When talking about software development, it is easy to think of developers’ everyday life as a continuous coding/review cycle, as a two-sided coin flipping endlessly. Of course, this is an oversimplification. There are many other responsibilities that a software developer may hold on a daily basis.

But when you get into the "coding zone" for a while, you know most of the time you are going to be either coding some task assigned to you or reviewing others' code already implemented.

Software development is not only about writing code, but about writing GOOD code. And code review is a crucial part of that quality process.

Do you like what you read? Share it with your friends via 👇🏻

💚 On WhatsApp

💙 On LinkedIn

🩵 Bluesky

1. Code Re-What?

Well, even if it is obvious for many, let's just briefly explain what is usually understood by Code Review. In short, Code Review can be considered a quality process to perform over any piece of code prior to its merging into the main branch of the codebase.

This review consists on a visual inspection of the code implemented by developers other than the author. As a fundamental part of software quality practices, it aims to improve the code by spotting any possible accident waiting to happen, such as:

Bugs or code malfunction.
Security concerns.
Performance and scalability issues.
Misalignment with team conventions or code style.
Poor design or misalignment with initial requirements.

2. This is getting serious

As you can see, there are a lot of things that could go wrong, and it is important to keep an eye on them, but do not panic. Code Review is usually considered a final (and very important) touch, when everything is (or should be) pretty much ok. In any professional software development team, a variety of conventions and tools are put in place to make the code as bullet-proof as possible by the time it gets into code review. Some of them are:

Basic code conventions for the team to follow. This guarantees everybody is on the same page when writing code and organizing projects.
Static analysis tools, in order to catch any possible issue without needing to run the code (basic errors, warnings, security hotspots, etc.).
Test coverage, crucial to understand what part of your code is involved in the tests already in place.
Code assistants, to benefit from AI-powered engines to implement part of the code.
Integrated Development Environments (IDEs), in order to have all these basic tools in the same place (editor, debugger, code assistant, etc.).
Automation pipelines for repetitive tasks (compiling, test running, static analysis, etc.).

3. Let's get the party started

Ok. So, I'm a happy developer who just finished a coding task. The code seems polished and ready-to-go (keep dreaming), and it is time to share it with the teammates for a review. This is the time when developers open a Pull Request (PR) or a Merge Request (MR), depending on the environment used. In any case, this request aims to integrate new code into the main branch of the codebase.

At this point, whatever tool you are using to handle this, the Code Review process typically works as follows:

Once an MR/PR is opened, reviewers must go over it to comment on possible improvements.
Ideally, every MR/PR should be checked by at least 2 reviewers.
For each reviewer's comment, the coder must either:
- Go for it, pushing the necessary changes, or
- Initiate a discussion/ask for further information from the reviewer, if unclear, or
- Reject the suggestion or change commented, providing the necessary reasons.
The coder must always reply to reviewers' comments, whatever the final decision on the comment.
Reviewers are to re-check the code when comments are tackled by the coder.
If happy with a comment resolution, the reviewer who opened the comment will be in charge of closing it.

Once the Code Review process is finished (no pending comments and approved by the reviewers), the coder can proceed with the merging of the code (yes!).

4. Zen of Code Reviews

After a while in the industry, I have a mental list of things I always comment on or suggest when discussing Code Review with colleagues. The most relevant points of it would be:

Do not start a code review if the code is far from ready. Already been mentioned before, but again: reviewers should give a final touch to the code, not to complete the feature or redo it because of the lack of quality. A code review is not a peer-programming session.
Code reviews are as important as the code itself. Forget about "I know how to write code, I can make software". When it comes to software development, coding is just half (I would say even less) of the story.
As a consequence, make sure you get into the code review fresh and full of energy; you will need to be focused for a while.
Do not fall for scroll-down-and-approve kind of reviews. Take your time to go over the code, understand it, and make a proper assessment.
Code reviews must not be limited to more experienced team members in the project or the technologies involved in the code review. It is great to have different perspectives.
Do not be shy or think your comments won't be important. Challenging plays an essential role in software quality.
Always be respectful and polite in the way you communicate with the team during a code review.
No, code assistants or AI-powered engines are not enough. There is always some risk or things to double-check on AI-generated code (e.g., hallucinations).
Code reviews are supposed to be an agile process. Both coders and reviewers must not leave them unattended for a long time.
Code reviews must always pursue an effort-benefit trade-off. They cannot be endless.
Code Review is an excellent way to spread knowledge within the team. By having a look at the code, reviewers not only help to increase the code quality, but they also keep up-to-date with the changes done by others, helping to decrease the learning curve in case they need to put their hands on that code later.
This very procedure could perfectly fit non-code-related review processes (e.g., documentation).

I hope you found this article interesting. Perhaps you even learnt something new, or it provided you with some discussion/investigation material.

I leave you to your ping-pong match...I mean, your code/review iteration. Have fun :)

🫂 Thanks Alberto!

Marcos back!

I want to send a deep Thank You to Alberto for sharing his experience with all of us. If you want to contact Alberto, you can reach out via LinkedIn 👉🏼 https://es.linkedin.com/in/albertocarrascomontenegro

You can find below a couple of interviews I’ve conducted with this great Software Engineer.