Code review. Management perspective

There are many articles and videos explaining why code review is so important for software developers and teams, but let's see what can we get from code review process from management perspective. We are not going to describe rules and processes of code review, but let's focus on non-obvious goals and obstacles.


Make high-quality product

This is the most obvious thing why many teams doing code review.

Rise and develop engineering culture

When code review process is introduced and accepted in the team, codebase starts to follow set of rules which are chosen by the team — people who do this review. This is an organic process, because people in team use more or less the same rules when they write code: rules for coding, approaches to architecture, favourite patterns and so on.
I can't say that it is just a set of rules for coding, but this is an engineering culture on practice. And if you are in a role or teamlead or project manager you may start to rise this culture or change the culture to follow modern approaches.

Team collaboration

Code review is a point where all team members are introduced. They exchange opinions and experience and we may try to introduce to review process as many peers as needed. In ideal case, every developer should take part in code reviews.


Code review can be used as powerful learning instruments for all: junior, middle and senior developers. Of course, if you keep that in mind. Juniors can learn how to write code, while more experience people can take away fresh and new approaches they even dod not think about.
It's important to write sufficient comments, ex. why one solution or approach is preferred in concrete situation and other can be not acceptable.

Enhance quality of the product

This is quite obvious goal. And many teams do their code reviews having only this goal in mind. And it works

Possible obstacles and drawbacks

Code review process has not only positive impact, but also may have some obstacles and drawbacks you should know about.

Learning punishment

This is happening when code review is launched in "default set of rules". Often less experienced assume that they should only do everything that more experienced colleagues tell them to do. And idea that code review is also a great place for learning is totally missed. Senior people also often provide their feedback in order-manner.
As a manager you need to explain you team this potential damage area and try to pivot the process into learning way.


There are also situations when many comments are related to spacing, unneded empty lines, places of curly braces or paying too much attention to naming. Of course, team should follow code style, but 101% following these guides is not the final goal. There should be any space for not to super-strictly following the rule. And in many cases this super detailed attention to small details does not add any value to end product.

Too long approvals

Code review is a process and as any process, it should be organised. Common problem is too long code reviews. Roots of this problem: lack of senior engineers that makes final approvals, too large pull-requests. Often teams has both of them. And this situation is often met in outsource companies or companies with remote workers.


This article is written based on practice, so described situations can be met very often. I hope you will bring positive things and will avoid all drawbacks in you team!

iOS developer, TeamLead. Love engineering, guitars, martial arts and learning