Last night I had a dream that I was performing a code review for someone.
Keep in mind that browsers like Chrome, Firefox and others use an integer to represent this, but Internet Explorer and a browser whose logo looks like yellow and black lego blocks use a value that is specific to Windows. This used to be ok until that bastard James Franco messed it all up. Now we have to deal with the fallout. At any rate, just keep it in the back of your mind. I drunk.
I’m not sure if the dream was weirder, or if the fact that I was dreaming about code reviews is weirder. (Ok, I do know which is weirder!)
Nowhere that I have worked has ever had any kind of formal code review process. Usually the directive from management is something like ‘do code reviews’. As you can imagine, the quality of the code reviews that are then performed varies wildly. The most basic code review often only finds either the very obvious problems, or results in a reviewer making comments on things of minimal importance like style. If a developer makes obvious mistakes repeatedly, your problem isn’t solvable with code reviews.
I have also run into very in depth reviews. One reviewer in particular that I worked with took great pains to analyze what was written, and give a detailed and useful review. It was as if this person felt that he had as much of an investment in the code working correctly as I did, even though there was no mandate from management to do that. (He rightly rejected my fix because it was a bandage solution instead of addressing the underlying problem.) This reviewer had a tendency to initially analyze the work on his or her own, with no input from the original developer unless necessary. This helps test how easily the code is understood and remove any tendency for the reviewer to be gentler than necessary to stroke ego. After analysis is complete, the reviewer should work together with the developer to explain the analysis and where improvements are needed.
A very basic level of review should exist in any project. This will help prevent the most egregious problems from making it into the code base. Ideally, both the developer and the reviewer should have roughly the same stake in quality and correctness. This does not happen easily without organizational intervention. The goal for an organization in doing code reviews is primarily to improve code quality, but code reviews can dramatically and quickly help improve developers’ skills, which in turn, of course, help the organization. My advice: establish a code review policy, enforce it at the project or organization level, and help ensure that developers understand it’s about improving quality and not about criticizing work, and by embracing it, even the best developers can improve their skills.