Keep in mind the overarching goals: in the end, only working software matters

Peer review and check-in code review have the goal to improve quality. But there's nothing worse for quality than a demotivated developper. As a team lead, your role is not to endorse the code as something that you could have written yourself, but to promote teamwork and ensure the overall result.

Set a clear scope for your review

Keep in mind: it's not your code, but the team's code. So, focus on things that could lead to wrong results.

• Don't challenge the way your developer has chosen to meet the requirements, unless you're certain it won't work (but it should already have failed the tests, no?)

• Don't challenge for poor performance unless there is a measure that shows where the issue is. Premature optimization is the root of all evil ;-)

• If you find a design or software structure to challenge, then ask yourself why it wasn't caught upfront! Already written code is expensive to rewrite. If this happen, it's time to review your software development and teamwork practices at least as much as the code.

• address compliance with established coding standards. It's the most annoying topic to discuss for both the reviewer and the reviewed. When everyone agreed to use capitalized class names in your team and one guy has a class without, is it a matter of taste ? Or of teamwork effectiveness and risk ?

By the way, if you feel a coding standard is not worth to be discussed, remove it form your standards and don't waste time and energy on it.

Develop leadership

As a team leader, you may find here an opportunity to develop yourself and your team, beyond the formality of a quality control:

• Code reviews are much more pleasant for everyone, if there's a true exchange. Give your developper the opportunity also to show their skills (and yes, perhaps you could learn something new).
• Have an open ear to criticism on design choices, or existing standards. Sometimes people can cope better with such frustrations, just because they could talk about it.
• Coach your juniors: don't hesitate to give advices, or refactoring orientations for the next iteration. Don't do this with seniors: in another world your respective role could have switched.

Take advantage of other practices

There are a couple of things that you can avoid in code-review:

• Use of a static code analyzer in your build chain can automate the finding of common bugs, or non portable constructs, long before the peer review. Some tools can even check for some of your coding standards.
• If you have standards about code layout, use a pre-commit pretty-print to format the code as required automatically. Never spend time on something a software could do for you better and without discussing :-)
• Finally, quality is not only ensured by review, but also by tests. If you don't use TDD yet, give it a thought independently of code review.

Keep in mind the overarching goals: in the end, only working software matters

Peer review and check-in code review have the goal to improve quality. But there's nothing worse for quality than a demotivated developper. As a team lead, your role is not to endorse the code as something that you could have written yourself, but to promote teamwork and ensure the overall result.

Set a clear scope for your review

Keep in mind: it's not your code, but the team's code. So, focus on things that could lead to wrong results.

• Don't challenge the way your developer has chosen to meet the requirements, unless you're certain it won't work (but it should already have failed the tests, no?)

• Don't challenge for poor performance unless there is a measure that shows where the issue is. Premature optimization is the root of all evil ;-)

• If you find a design or software structure to challenge, then ask yourself why it wasn't caught upfront! Already written code is expensive to rewrite. If this happen, it's time to review your software development and teamwork practices at least as much as the code.

• address compliance with established coding standards. It's the most annoying topic to discuss for both the reviewer and the reviewed. When everyone agreed to use capitalized class names in your team and one guy has a class without, is it a matter of taste ? Or of teamwork effectiveness and risk ?

By the way, if you feel a coding standard is not worth to be discussed, remove it form your standards and don't waste time and energy on it.

Develop leadership: the human side of the review

As a team leader, you may find here an opportunity to develop yourself and your team, beyond the formality of a quality control:

• Code reviews are much more pleasant for everyone, if there's a true exchange. Give your developper the opportunity also to show their skills (and yes, perhaps you could learn something new).
• Have an open ear to criticism on design choices, or existing standards. Sometimes people can cope better with such frustrations, just because they could talk about it.
• Coach your juniors: don't hesitate to give advices, or refactoring orientations for the next iteration. Don't do this with seniors: in another world your respective role could have switched.

Take advantage of other practices

There are a couple of things that you can avoid in code-review:

• Use of a static code analyzer in your build chain can automate the finding of common bugs, or non portable constructs, long before the peer review. Some tools can even check for some of your coding standards.
• If you have standards about code layout, use a pre-commit pretty-print or similar formatters to format the code as required automatically. Never spend time on something a software could do for you better and without discussing :-)
• Finally, quality is not only ensured by review, but also by tests. If you don't use TDD yet, give it a thought independently of code review.