[97 Things Every Programmer Should Know – #14] Code Review: More Than Finding Bugs
Summary
Code reviews are commonly used to improve code quality and reduce defects. However, their value extends beyond identifying mistakes. Effective code reviews encourage knowledge sharing, establish consistent development practices, and promote collective code ownership. The key is to make reviews collaborative and constructive rather than rigid, intimidating, or dependent on a single reviewer.
Why Do Code Reviews Sometimes Become a Burden?
Code review is widely considered an essential software development practice. Its primary purpose is often understood as finding errors before they reach production.
However, not every code review process produces positive results.
Some companies require all code to be approved by architects or lead developers before release. While strict reviews may be necessary in certain environments, applying them to every situation can create unnecessary bottlenecks.
When one person is responsible for reviewing everything, that reviewer must continuously maintain detailed knowledge of the entire system.
Developers may also feel that their work is being judged rather than collaboratively improved.
Over time, reviews can become slow, stressful, and unproductive.
The problem is not code review itself, but how the review process is organized and conducted.
Code Review Is Also About Sharing Knowledge
According to Mattias Karlsson, the purpose of code review goes beyond detecting defects.
An equally important goal is to ensure that team members understand one another's code and follow consistent development practices.
When developers review code written by their colleagues, they gain insights into unfamiliar parts of the system.
This encourages collective code ownership, where knowledge and responsibility are shared across the team rather than concentrated in one individual.
Instead of relying exclusively on senior developers, teams can rotate reviewers and involve different members in the process.
Reviewers should approach each session with two objectives:
- Identify potential problems and suggest improvements.
- Learn how the reviewed code works and understand the decisions behind it.
This approach turns code review into an opportunity for continuous learning.
How to Make Code Reviews More Effective
1. Rotate Reviewers and Involve the Whole Team
Code reviews should not always be assigned to the same senior developer or architect.
Rotating reviewers distributes knowledge and prevents the review process from depending too heavily on one person.
New team members should also be encouraged to participate.
Although they may have limited professional experience, recent graduates can contribute knowledge from their studies and offer different perspectives.
At the same time, experienced developers provide valuable insights by recognizing error-prone code and potential design problems.
A productive review benefits from different levels of experience, not just seniority.
2. Define Clear Responsibilities
To prevent organizational hierarchy from dominating the discussion, reviewers should have clearly defined roles.
For example, responsibilities can be divided into:
- Documentation: Check whether comments and documentation are appropriate.
- Exception handling: Review how errors and exceptional situations are handled.
- Functionality: Verify whether the code behaves as expected.
Distributing responsibilities helps reduce individual workload and gives each reviewer a clear focus.
These roles can also rotate between review sessions, allowing team members to gain broader knowledge.
3. Establish Consistent Coding Standards
Code reviews become less productive when discussions focus on minor formatting differences.
Teams should agree on consistent coding rules and use automated tools to check whether those rules are followed.
When formatting and other mechanical checks are handled automatically, reviewers can spend more time discussing functionality, potential defects, and design decisions.
This makes reviews more meaningful and reduces unnecessary disagreements.
4. Make Reviews a Regular Team Activity
Rather than treating code reviews as occasional inspections, teams can establish a regular schedule.
Mattias Karlsson suggests holding a weekly review session lasting approximately two hours, with the code author and reviewers rotating over time.
This is one possible approach, not a fixed requirement for every project.
The goal is to create a predictable opportunity for developers to examine code together and share knowledge.
A Good Code Review Should Feel Collaborative
The attitude of the participants is just as important as the process.
Feedback should be constructive and focused on improving the code, not criticizing the person who wrote it.
Harsh comments can discourage participation and make developers reluctant to share their work.
A friendly, relaxed environment encourages questions, discussion, and learning.
Karlsson even suggests that reviewing code over lunch or snacks may be more productive than conducting an intimidating formal meeting.
The message is simple: People learn better when they feel comfortable participating.
Here is how the two approaches compare:
| Ineffective code review | Effective code review |
|---|---|
| Focuses only on finding mistakes | Finds defects and shares knowledge |
| Depends on one senior reviewer | Rotates reviewers across the team |
| Uses harsh or personal criticism | Provides constructive feedback |
| Repeatedly debates formatting | Automates coding standard checks |
| Creates pressure and delays | Encourages collaboration and learning |
Applying This Lesson to Software Development Teams
For software development teams, code review should be treated as both a quality assurance activity and a way to strengthen collaboration.
This is particularly relevant when several developers contribute to the same system.
A review process that distributes knowledge can help team members understand more of the codebase and reduce reliance on individual experts.
For teams such as VAON, the principles in this chapter provide useful considerations when defining development workflows:
- Encourage participation from developers with different experience levels.
- Keep feedback respectful and focused on the code.
- Automate routine checks wherever practical.
- Make knowledge sharing a core objective of review sessions.
However, teams should adjust the frequency and formality of reviews according to their project requirements. Some environments genuinely require stricter controls.
The goal is not to eliminate review discipline, but to balance quality assurance with learning and productivity.
Conclusion: Code Review Is About People, Not Just Code
Code reviews help improve software quality, but their benefits go far beyond finding bugs.
They create opportunities to share knowledge, establish common standards, and build collective responsibility for the codebase.
To make reviews effective, teams should rotate participants, define responsibilities, automate routine checks, and maintain a constructive atmosphere.
Most importantly, code reviews should be activities that developers want to participate in, not meetings they fear.
A successful code review improves both the code and the team behind it.
About This Series
97 Things Every Programmer Should Know explores practical lessons about software development, code quality, collaboration, and professional growth.
This article is based on #14 – “Code Review”, written by Mattias Karlsson, from 97 Things Every Programmer Should Know, edited by Kevlin Henney.
The article summarizes the original chapter's central ideas and organizes them for software development teams.
Learn more about VAON and our software development services.