When we create programs in a professional way, it is done in teams. There is no one-man show programming other than in a hobby or going along with the tutorials. It is not only because it is more effective to work in teams but also because one person is vulnerable. If you work alone and get hit by the bus or you hit the lottery and lose your ability or motivation to work on the project, your customer is in trouble. That is not professional. Professional projects should be resilient to any member falling off.

Teamwork needs cooperation and one form of cooperation is code review. This is the process when a developer or a group of developers reads a part of the code that some other team members have written. There are direct gains from this activity;

• The developers reading the code get more knowledge about the code; they learn the code. This way, if the developer creating the code gets out of the process for any reason, the others can continue the work with minimal bump.
• Coding styles can be aligned. Developers, even seniors, paying careful attention make coding mistakes. This may be a bug or it may be a coding style violation. Coding style is important because the more readable the code is, the less possibility of it having unnoticed bugs. (Also see the next bullet point.) It is also important that the coding style is the same for the team. All team members should use the same style. Looking at a code that has a different style from the one I wrote is a bit harder to follow and understand. The differences may distract the reader and the team members have to be able to read the code. The code belongs to the team and not a single developer. Any team member should know the code and be able to modify it.
• During code review, a lot of bugs can be discovered. The parties looking at the code and trying to understand the working of it may occasionally discover bugs from the structure of the code, which are otherwise hard to discover using tests. If you want, code review is the whitest white box test. People think differently and different mindsets catch different bugs.

Code review can be done online and offline. It can be done in teams or peer-to-peer.

Most teams follow the code review process that GitHub supports, which is the simplest. Changes to the code are committed to a branch and are not merged with the code directly but, rather, a pull request is created on the web interface. The local policy may require that a different developer perform the pull. The web interface will highlight the changes and we can add comments to the changed code. If the comments are significant, then the original developer requesting the pull should modify the code to answer the comments and request the pull again. This ensures that at least two developers see any change; the knowledge is shared.

Feedback is peer-to-peer. It is not a senior teaching a junior. That needs a different channel. Comments in GitHub are not good for this purpose; at least, there are better channels. Perhaps talking face to face. Comments may come from a senior to a junior or from a junior to a senior. In this work, giving feedback on the quality of the code, seniors and juniors, are equal.

While change review and GitHub is a good tool during development, it may not be appropriate when a larger chunk of code has to be reviewed. In such a case, other tools, such as FishEye, have to be used. In this tool, we can select the source files for review even if they were not recently changed. We can also select reviewers and deadlines. Commenting is similar to GitHub. Finally, this type of code review finishes with a code review session, where the developers gather and discuss the code in person.

While organizing such a session, it is important that a person who has experience managing other people mediates these sessions. Code and discussion on styles can get very personal. At the same time, when attending such a meeting, you should also pay attention so as not to get personal. There will be enough participants who may not know this or are less disciplined.

Never attend a review session without reviewing the code first using the online tools. When you make comments, the language should be very polite for the reason I have already mentioned. Finally, the mediator of the meeting should be able to separate important and not so important issues and to stop debate on bagatelle things. Somehow, the less important issues are more sensitive. I personally do not care about formatting the tab size if it is two or four spaces and if the file should contain only spaces or if tab characters are allowed, but people tend to like to waste time on such issues.

The most important issue during code review sessions is that we are professional and it may happen that I review and comment your code today, but tomorrow, it will be just the opposite, and we work together and we have to work together as a team.