Are You Too Good For Code Reviews? 495
theodp writes "Why do some programmers,' asks Chris Hemedinger, 'place little value on code reviews?' This apparently includes even Programming Greats like Ken 'C' Thompson, who quipped, 'we were all pretty good coders' when asked about the importance of code reviews in his work. Hemedinger, on the other hand, subscribes to the school of thought that peer code reviews are Things Everyone Should Do. Not only do reviews keep you on your toes, Hemedinger says, they also 'improve quality, ensure continuity, and keep it fresh. Who can argue against that?'"
Re:Pure Arrogance (Score:5, Interesting)
Because if it's written with an eye only towards effectiveness, and not towards standards and readability by others; then by the standards of any project larger than "A script I use to clean up my home directory" it's crappy. He's being kind of an arrogant ass about it, but his overall point is completely valid. If you quit or get run over by a bus tomorrow, and I (for a value of "I" that indicates a competent peer familiar with your company's standards and the language in question) can't pick up your project/module and continue development/support then it's not "good" code no matter well it works. That doesn't mean you can't be creative and awesome in your implementation, it just means you have to write the shit so someone else can read it; and in a pinch finish/fix it. That's what standards are for.
Re:I agree 100% (Score:4, Interesting)
I have a huge ego. I freely admit it. I work from home because I can't fit my ego in the office doors.
On a serious note, I prefer code reviews. From the ego-centric side, it has two major benefits: it allows my ego to show off, second it helps the less-experienced/newer developers to learn new techniques, or just learn the code, often in areas they haven't spent a lot of time looking at. That means less time helping them later. It also happens to have the side benefit that their questions can make me think about the problem harder, and not-infrequently uncover typos, thinkos, under-developed (or over-developed) features, or plain bugs. Even for us egomaniacs.
Re:I agree 100% (Score:4, Interesting)
I've found that code reviews are most productive if you pair experienced and inexperienced coders. An experienced coder is probably writing good functional code, but may not be writing code that's easy to understand. Having code reviewed by someone less experienced helps catch things where someone new to the codebase would struggle to understand the code. This should prompt additional comments or (ideally) refactoring into a clearer form. The inexperienced developer also benefits from being forced to read and understand someone else's (hopefully good) code. In the other direction, the inexperienced developer gets helpful feedback on their design and techniques.
Code reviews done by someone with a similar skill level tend to be a waste of time. They'd typically implement things in more or less the same way, so they either skip over things and don't give much feedback or they're really pedantic but not very helpful.