This story is about sins in code review processes, inspired by my experience, observation, and self-reflection.
Code review is a collaborative process in which developers examine and critique each other’s code changes to identify errors, ensure consistency, and improve overall quality.
Forgive me, Father, for I have sinned. I’ve walked a dark path where code review stopped blessing the team and turned into the joy of sins, conflicts, and the spreading of evil.
The Sin of “Redundant Spaces”
- What it looks like: I’m focusing on the formatting of the code, ignoring all the changes, and concentrating on the things that do not bring business value. I am not looking for problems. I’m looking for redundant spaces.
- Why it’s bad: It wastes time and annoys the author. Real problems stay undiscovered.
- How to repent: Discuss with a team following code style and using automated formatting tools. Let the computer handle these style issues and focus on architecture and logic.
The Sin of “Subjective Taste Wars”
- What it looks like: I carry my cross on this crusade, delivering knowledge for everyone to accept. This solution shouldn’t be done in this way. Believe in SOLID and TDD, and you’ll get my blessing. I’m spreading and fighting for my personal preferences without referencing code conventions or pointing to potential benefits.
- Why it’s bad: It sparks conflicts, extends review cycles, and destroys trust. Code review should be about overall quality, not personal whims.
- How to repent: Define team-wide standards (code conventions). Follow code conventions consistently and give feedback based on this or point to the benefits.
The Sin of “Vague or Hostile Feedback”
- What it looks like: I’m right, my words are True, you’re never a good coder, and your solution is disgusting as hell. Why do you do this?
- Why it’s bad: A toxic discussion about the solution, pointing directly to the author, develops a bad atmosphere in the team. The author feels confused and offended and loses motivation. Collaboration, constructive feedback, and respect for teammates are keys to success.
- How to repent: Be specific: “This function may cause memory leaks. Let’s try to adopt your solution using this cool guideline about memory optimization”. Offer actionable suggestions. Respect the author and his work. He put effort into developing a solution and wanted to hear constructive comments about the solution, not himself. Remember: The author’ code is not the author.
The Sin of “Massive PRs”
- What it looks like: I’m very excited about my code. I was so productive that I sent an insanely large pull request to the review. My teammates are skilled and could review it quickly!
- Why it’s bad: Reviewing big changes is hard. Reviewers miss essential details about implementation and want to finish it faster. As a result, the quality of the code review process decreases, problems are overlooked, and frustration rises.
- How to repent: Break down big changes into small ones. Focus on making the process of review easier. Put yourself in a teammate’s shoes. You don’t like reviewing thousands of lines of changes they don’t like, but why do you keep doing this?
The Sin of “Scrolling Over The Code”
- What it looks like: I’ve received a pull request. Let’s give the code a quick once-over and wrap up this review. I’m leaving a couple of comments that I believe illustrate my reasoning.
- Why it’s bad: Code review is designed to catch bugs earlier and improve solutions, not just to check a box. Surficial reviews miss the issues, leading to more significant trouble.
- How to repent: Find time to read changes from pull requests carefully. If you can’t, communicate with the author and ask for time or switch to another teammate.
The Sin of “Ignoring Colleagues’ Time”
- What it looks like: I received a review request but keep putting it off. I’ll do this later, maybe tomorrow or next week.
- Why it’s bad: Code review is often a blocking step in the SDLC (Software Development Life Cycle), which blocks the next releases, slows down the team, and demotivates the author.
- How to repent: Prioritize code review, as mentioned in the previous sin—find a time in your schedule and return to the author if you can’t find a time. With the earlier feedback, the author could reassign the pull request. Quick feedback is key to healthy workflows and a positive team spirit.
The Sin of “Ignoring the Comments”
- What it looks like: The reviewer points out a real problem or a valuable improvement, but I either forget about it or apply a half-baked fix.
- Why it’s bad: The review process loses meaning if comments are left unattended and bad solutions are deployed to production. Reviewers could be demotivated as a result.
- How to repent: After discussions, address the issues or explain clearly why you disagree with the comment, but make sure you hear what the reviewer wants. Code review is a team effort, and decisions reached in the review should be reflected in the final code or discussed.
At the end
Code review is one of the best techniques for keeping your codebase current, enforcing internal standards, and catching issues early in the SDLC. When done right, it’s a powerful tool that drives quality and collaboration.
Simply integrating code review for integration can spread chaos in your team — lowering performance and killing motivation. Instead, invest in an improving review process that values quality over speed, turning every review into an opportunity for improvement and shared learning.
If you enjoyed the story, follow it and leave comments on how you deal with code review. Your support and activity mean a lot to me.