Avoiding the Pitfalls of Code Approval: Lessons Learned from Approving Bad Code

Have you ever approved code that, upon deployment, turned out to be problematic? I can say from experience that it is a frustrating yet necessary part of the software development process. In this article, I will discuss a specific instance where a junior developer's poorly implemented code caused significant issues and the lessons I learned from this experience. Additionally, I will delve into the common mistakes made during code reviews and how to mitigate them in future projects.

Approving Suboptimal Code: A Junior Developer's Mistake

One instance of approving bad code involved a junior developer who wrote a service for onboarding new consumers. Despite the service being relatively small and simple, it was a critical component of the system. Due to its simplicity, I didn't spend much time reviewing the code, assuming the core logic was solid.

However, problems arose when the service was deployed to different customers. Error messages were consistently unhelpful, and it took considerable time to identify the root cause. Eventually, I had to make a minor change to the code, which led me to discover the root of the issue. The junior developer had ignored the baked-in error logging system and instead opted to log only the stack trace, assuming it was sufficient. This oversight was enlightening and highlighted a critical flaw in the review process.

Common Challenges and Lessons Learned

Luckily, this wasn't the first time I had encountered approving poor quality code. I can recall instances where the original developer failed to properly understand the requirements or conduct adequate testing. These situations demand a meticulous and methodical approach, especially in projects that handle sensitive data or involve significant business logic.

When reviewing code, I often focus on identifying potential gaps and ensuring that the core logic is sound. However, coding is inherently a collaborative effort, and there are times when we must rely on the judgement and expertise of our peers. While it's ideal to work with developers whose work we can trust, such an ideal scenario is not always possible. This is especially true for projects that don't involve direct handling of money, authentication, or other critical systems.

Striking a Balance in Code Reviews

The key to effective code reviews lies in striking a balance. For less critical code or in branching situations, less intensive reviews can be sufficient. However, if the code is sensitive or high-risk, or if it needs to go into production quickly, a more thorough review is necessary. Approving bad code in such scenarios can lead to significant downtime, user frustration, and system instability.

It's essential to understand that performing a thorough code review can be time-consuming and energy-intensive. Expending a significant amount of effort reviewing every piece of code can be as time-consuming as writing the code itself. For this reason, it's crucial to prioritize the areas where the most potential risks lie.

In summary, while approving code inevitably involves some risk, being aware of the potential pitfalls and taking the necessary steps to mitigate them can help ensure that the codebase remains robust and reliable. By learning from past experiences and adopting a strategic approach to code reviews, we can significantly reduce the chances of approving poor quality code.

Conclusion

Approving code can be a double-edged sword. While it's important to trust the developers on your team, it's equally crucial to remain vigilant and ensure that the code meets the necessary standards. By learning from past mistakes and adopting a strategic and balanced approach to code reviews, we can minimize the chances of approving bad code and ultimately contribute to the success of our projects.