First of all, what is Code Review? Let’s borrow from Wikipedia:

Code review is systematic examination (often known as peer review) of computer source code. It is intended to find and fix mistakes overlooked in the initial development phase, improving both the overall quality of software and the developers' skills.

This definition gives a good idea of what Code Review is. In my opinion there’s more to it than only that.

I’ve worked with and without Code Review. While it’s feasible to work and produce software without it (many companies still do it) from experience I believe the advantages of using it are enormous.

Like the above the definition states, this practice aims at finding and fixing mistakes overlooked during initial phases of development. It will serve as a first phase of Quality Assurance (QA). These mistakes can be from a wide range of sources ranging from bugs in the code, to some problem due to lack of knowledge about the platform being developed, or even misunderstanding the development task at hands. This by itself makes this practice very useful.

This technique it’s also important to help a developer improve his skills. I witnessed this in the first person. The fact that the code is reviewed by someone with more experience (in a specific programming language, framework, system, etc) will help a developer grow much faster. It’s invaluable, trust me.

Another point that I believe it’s very interesting in Code Review is the fact that it makes other developers aware of what you are doing. How many times have you been handed some piece of development from another developer who, by some reason, was unable to complete it (because of illness, left the company, etc) and no one knew exactly what was going on? This will guarantee that, at least, someone else is aware of what was done and can put you up to speed regarding the path followed.

A very interesting side effect technique is the fact that it allows your line manager to be aware of your skills and progress as a developer. This will enable your managers and colleagues to help you strengthen your weaknesses. It will also make your evaluations easier and much more accurate.

It’s my belief that when this practice is put in place many other advantages can be found. But, it has to be used conveniently! Several times I’ve seen conflict rise up between reviewer and reviewed. That tension can appear from either sides.

This process should be an interactive, between the two parties. That means that it will be a back-and-forth of reviews. And it doesn’t necessarily mean that the reviewer will always be right. When the reviewed does not agree with something can, and should, make it’s on opinion “heard”, explaining the reasons for not agreeing. You would be surprised with the power of this process.

As the previous paragraph reveals, one of the most important skills for using this technique is good common sense. This approach should not be used as an opportunity to make negative criticism or even make others look bad. It’s my belief, and my experience gives me proof, that such an approach will in fact improve software quality and will help everyone involved in the process to improve not only technical skills but also personal skills such as interacting with one another.

My answer to the question? Yes. A very big YES!