Code reviews and proofreading your code

Apart from our regurlar scheduled weekly codereviews, which has the usual benefits, lately, some developers of the team I am working with are actively started asking me to proofread their code.

I am very happy about that because going over the code with somebody else will catch bugs, enhances the style of the code (and thus the writing) and eventually save your company money.

Unfortunately, just as Simon Johnson asks in his blog
Do you proofread your code? the thing is that reading somebody else's code takes time.

Let me quote from that blog:

It is entirely possible to do a formal inspection but be intellectually lazy about it. Any such approach is doomed to fail. Rigour means that you need to sit down and really concentrate hard on the code in question and not just go through the motions of a formal process.

If this sounds like hard work, it is.

Personally as teamlead I think it is of upmost importance for developers to review code and work as a team. But that also means it should not be only me, as in teamlead, who they should get agreement from before they commit changes to SVN. Developers should get agreement from the entire team.

The thing that probably will work is what Jeff Atwood writes about which is having coding buddies. That is, after every change in code a developer asks a teammember to review the changes.

Reviews should not be an obligation at pre-commit time to the trunk because that will only put a burden on commits or result in poor reviews which defies the cause. Reviews can also take place later as long as the review does take place within a day or two otherwise the changes are not fresh enough anymore for an effective review. Reviews preferably take place right before a developer wants to commit changes.

An interesting video about code reviews is what is done at google with Mondrian which is a presentation about google's online webreview tool, taking reviews as far as building complete tools around the entire review process.

Anyway, my point is: The goal of code reviews is to make code better. It is NOT about setting up formal ways of checking up work of your collegues or teammates. Ego's should go away, code reviews are there for improving the quality of the codebase.

Or, as Martin Golding says: "Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live."