Chapter 14. Review the code
One of the biggest mistakes that new software team leaders make is to consider the code written by the programmers as the private property of the author, as opposed to an asset owned by the team. This causes the team leaders to judge code based on its behavior rather than its structure. Team leaders with this dysfunction will accept any code as long as it does what it’s supposed to do, regardless of how it’s written.
Indeed, such team leaders often don’t bother to read other programmers’ code at all. They satisfy themselves with the fact that the system works and divorce themselves from system structure. This is how you lose control over the quality of your system.
Once you lose control, the software will gradually degrade into an unmaintainable morass. Estimates will grow, defect rates will climb, morale will decline, and eventually everyone will demand that the system be redesigned.
A good team leader takes responsibility for the code structure as well as its behavior.
A good team leader acts as a quality inspector, looking at every line of code written by any of the programmers under their lead.
A good team leader rejects a fair bit of that code and asks programmers to improve the quality of that code.
A good team leader maintains a vision of code quality.