The latest articles on DEV Community by André Degaspari (@andre_degaspari). https://dev.to/andre_degaspari https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4136011%2F72f9c92f-7221-4d0f-9438-e1c14d4c590d.jpg https://dev.to/andre_degaspari en André Degaspari Mon, 21 Sep 2026 18:53:53 +0000 https://dev.to/andre_degaspari/how-code-reviews-made-me-a-happier-developer-2n7 https://dev.to/andre_degaspari/how-code-reviews-made-me-a-happier-developer-2n7 <h2> Something I've always wondered about </h2> <p>I have always asked myself why, even with well-defined code guidelines, architectures, and design patterns, most of the time when I see a new application the code seems like it started from a good point and is getting messier and messier.<br> I know devs are usually running against time, dealing with short deadlines and scope changes, and these are good excuses for writing suspect code.<br> But we end up in the situation I mentioned above: codebases that start well and "suddenly" feel like we can't handle that monster full of code coupling, code we can't understand, and a small change that can break half of the application.<br> It is here that good code reviews come in handy to increase our quality of life as devs.</p> <h2> What I think about when doing a code review and why </h2> <p>When the dev starts the code review putting themselves in their client's shoes, and especially in their own future shoes, the code review becomes a mission instead of a simple click on the approve button.</p> <p><strong>Things I care about when reviewing code:</strong></p> <ul> <li>Does the code reflect the feature we would like to have in production being used by our clients?</li> <li>Does the code reflect the quality standards we dreamed of when we started the codebase?</li> <li>How can I help my colleagues with my review?</li> <li>How can I make my life easier in the future if I have to work on this code?</li> </ul> <p>To be honest, <strong>I have two reasons behind these questions</strong>.</p> <p>First, I really like helping my colleagues, so I love when I have a chance to teach something new to a fellow developer. Through code reviews we can boost careers, create great devs, and teach <strong>or at least spark interest in</strong> complex topics related to software architecture.</p> <p>As an example, I can share a situation I went through at work, one of the microservices I was working on had been started by another dev using hexagonal architecture and domain-driven design and after some time of development, the team formations changed.<br> It was a good surprise to encounter such a good architecture in the codebase, but as the gatekeeper responsible for reviewing what got merged into our releases, I noticed some devs didn't yet have enough knowledge to keep the codebase up to the standards the original creators had set.</p> <p>I could choose between <strong>letting the codebase degrade</strong>, finding myself in that old situation where something started good and became a mess, <strong>or helping my team reach a new level</strong> and make everyone's life easier.</p> <p>Review by review, I started pointing out what was misplaced in the PRs, sharing articles on why I was asking for changes, and eventually hopping on calls to explain a concept. <br> In a short time, I could see my teammates learning and thinking twice before making a decision and submitting a pull request. Those few hours I spent sharing knowledge led to better PRs and kept the codebase up to standard.<br> Another great outcome was seeing that other devs started caring more about code review too, sharing their own opinions so we could improve and, especially, not let our codebase health decline.</p> <p>This kind of investment pays off more broadly: we can also easily spot bugs before they go to QA, reducing the QAs' workload and preventing our backlog from increasing, which helps our PMs too. This means two other fronts of our team end up with a bit less work.</p> <p>This alone puts me in a position where I'm surrounded by better devs, who will eventually retribute my contributions by teaching me when they have the opportunity, and also in a team that is under a bit less pressure thanks to the issues we catch during code review.</p> <p>Second, I'm not a fan of working under pressure or late at night.</p> <ul> <li>Ensuring the feature was developed as expected for the clients prevents emergency tickets in the future caused by something being done in a way that wasn't planned.</li> <li>Ensuring the code follows the defined standards for the codebase puts me in a position where I know we'll have code that is easy to understand and therefore sustainable when we need to change it in six months.</li> <li>Ensuring the code follows the correct architecture/design pattern for each situation also makes my life much easier when the moment for a change or extension comes, and it will come.</li> </ul> <p>Notice I'm not talking about linting issues or missing code coverage, we can set up pipelines to check those kinds of things.<br> I've also seen code reviews created by AI that, in many cases, create slop, flooding PRs with comments and not really catching the points that matter, in my opinion, which I mentioned above.</p> <h2> Conclusion </h2> <p>At the end of the day, a good code review costs me 30 minutes to an hour of focused attention.<br> What I get back is a codebase I'm not afraid to touch in six months, colleagues who are a little closer to becoming the devs I'd want on my team, and one less reason to get a message at the end of my shift asking me to fix a bug.<br> The company benefits from that too, but that's not why I do it, I do it because it can be the difference between a job I survive and a job I actually enjoy.</p> codereview softwareengineering architecture