No, it’s not about the peer code review. Colleagues go easy on each other. They get lazy. They can’t be held accountable if a low quality code will sneak into the final product. Ain’t broke, don’t fix. I know about code coverage tooling too. They can help to some extent. But nothing beats the code review performed by a team lead. You can’t even imagine what can you find in people’s code.

First of all it’s like “Lost and Found”. The amount of the dead code is substantial (I know, some code quality tools can find it automatically). But morst importantly, people write poorly structured and inefficient code that can be easily identified by an experienced eye.

– Why did you write three loops, couldn’t you do it in one?
– Yes, I meant to change it later, but just forgot about it.
– We’ve agreed on using a fluid grid on this screen, where is the CSS?
– Sorry, I decided to cut corners cause the proper CSS was not obvious in the first place – I’ll change it now.
– What was the point of modularizing the application if you load all the modules on the application startup?
– Oops, no worries, give me a couple of hours and I’ll fix it.
– Why is this variable static? Do you really need to share it between all instances?
– C’mon, don’t be anal picky. You know how it works. Ok, give me an hour.

Let’s announce the first working day of the month
“A Code Review Day”.

During this day the most senior person in your team does nothing but reviewing the code of more junior colleagues. It’s not likely that you have more than 4-5 developers per team lead. Allocate two hours per person, and you’ll be surprised. You won’t believe your eyes. You’ll start pulling your hair out. You’ll be laughing and crying. Yes, people can write such code. They are not bad people, and you can keep going for a beer with them. They just don’t care. Sometimes. Ain’t broke, don’t fix.

Don’t get frustrated. Don’t report your findings to your manager. Just quietly and politely ask people to f#@ing clean this mess! The next month do it again.

Now, when can you say that the code is written well? I’ll tell you the secret. I’ve learned it while writing programming books. Here the rule:

“The code is good if it can published in a book”.

The readers are mean. They are not forgiving any little mistake. Most of them would never survive a book writing project, but they are happy to point at every little problem in your code samples. If you are a team lead, use the same tactics – read and ask to explain each questionable line of code, but be nicer than the readers.

Agreed? Propose “The Code Review Day” during the next team meeting. If your developers are standing during such meetings ask them to sit down, cause some may faint when they hear this.

That’s all there is to it. Please share your success story if you’ll manage to implement this practice in your organization – just add a comment to this blog.