Code reviews

Some thoughts I have on how to organise code reviews when you are a team leader (at least this is what I try to follow):      

• Code changes need to be reviewed before merging it to Master branch and before testing.

• As a leader, code review all changes done by other people, but ensure that everybody else is involved in code reviews (others don't have to code review everything, but ensure that everybody does some code reviews).

• Ensure that your code is always code reviewed by your team members and always react positively when a problem is found with your code, make changes to the code you written based on advise of the junior team members. This will ensure that the team members don’t see a problem someone found in their code undermines their position.

• Don’t nitpick, accept that different people write code differently. Insist on modifications to the work you reviewing only in a case of a bug or if the change that does not fit with overall design. Be polite and try to explain the reason.

• Have coding standards and ensure that tools for automatic code formatting are used (in case of Java IDEs both Eclipse and IntelliJ allow this and you can copy formatting rules between computers — when someone joins the company, just send them the formatting setup file). This will prevent “formatting wars” and comments about formatting.

• Have static code analysis tools run as part of CI (e.g. Sonar), this will reduce disagreements — psychologically it is easier to accept criticism from a machine then from a fellow developer.