Code review is one of the least glamorous parts of a developer’s career.[ref]I say “one of” because it’s really a toss-up between code review and unit testing. No one ever seems to want to do either.[/ref] It’s also one of the most necessary.
Code review helps you
It doesn’t matter how good of a programmer you are, someday you’ll make a mistake. Making sure your code is reviewed by a peer before it ships is just one of several safeguards you should have in place to prevent broken code from making it into production.
Once upon a time, I worked with a polyglot development team. I loved it because I had the ability to work across a variety of programming languages. Unfortunately, the rest of the team was not as interested in looking at the languages and frameworks I used as I was. Often I’d ship an accidental bug (usually a typo that still compiled), and we’d break something on the server. I’d look back to the logs to see who reviewed my code and follow up directly – the conversation was always the same:
“Hey, we shipped broken code today.”
“Yeah, apparently you had a bug,”
“According to the scrum board, you did the code review before I shipped. Did you miss it?”
“Dude, you know I can’t read your code. I just see your name on the ticket and assume it’s good.”
I like to think I’m capable of writing perfect code, but I know I’m not. Having code reviewed – frequently – by others on the team helps me to find where my code is nonsensical (so I’ll add documentation), too clever (so I’ll refactor), or just plain broken (so I’ll rewrite it to actually do the job it’s supposed to).
It helps the team
No one likes to have their code reviewed; not the senior lead, not the junior new hire. But it’s a task that helps strengthen the team all around.
If your code is miles above what the rest of the team can write, code review will help you refactor and document to make things more attainable for other developers. It also provides you the opportunity to teach other members of your team a new trick or two with code.
In the same vein as the previous story, I once shipped what turned out to be a too-clever fix to a database issue. It slipped through code review due to another “I see your name on the ticket and just hit approve” issue and launched to production.
Later that night I found myself explaining the patch to a colleague – I wanted some practical feedback on the approach and was still unsure it was the right way to go. They listened to my description, and immediately saw a flaw in my logic. It turned out my patch would irreparably damage the database at midnight (when a scheduled task was set to run my code).
A few panicked phone calls later and I had the change reverted. The developer who originally “reviewed” my code went back to take an actual look at things, saw what I did wrong, and further patched the mistake.
He then went on to release a separate application based on the same technique – an application I know is used on several very large websites. Reviewing my code not only helped improve the project, it also helped expand the capabilities of the team as a whole.
It’s the right thing to do
Code review is usually the nasty bottleneck keeping your code from deploying. It’s also a necessary bottleneck to ensure that it’s your code that deploys and not a catastrophic bug instead.
I insist that everyone on my team reviews code, and that everyone’s code goes through review before it hits the server. Two sets of eyes are always better than one.