Benjamin made an interesting observation when we were discussing our code review product a while ago.

Why do computer science students have so much trouble going through the code review process when they’re so comfortable turning in an essay and getting it handed back drenched in red pen?

The educational system has trained student after student when writing for a humanities class:

1. Work on the first draft of your essay
2. Hand it in, get back a (hopefully) careful examination by your eventual grader with suggestions ranging from punctuation tweaks to entire theme rejections
3. Work on your next draft
4. Hand it in, hope for a good grade and a complimentary paragraph of red pen feedback on the last page

This detailed feedback bothers some students, but it happens so often that you pretty much have no choice but to get used to it or you’ll go insane by the time you reach 7th grade, let alone college graduation.

Here’s how the typical computer science project compares:

1. Get a programming assignment
2. Work on it (possibly with a team) until the thing compiles and does something like what it’s supposed to
3. Put it on the right server before the deadline and, if you’re good, get an A back. If your professor is good, you might even get a nice complimentary paragraph about the extra feature you added.  If your TA is good, you might get one or two suggestions about how to improve your code.

I’m sure students have plenty of different experiences.  Before any TAs get mad, whether or not it’s more time consuming to read and understand tons of code than to grade written essays isn’t as important as the fact that it just doesn’t happen nearly as often.

Picture courtesy of http://is.gd/gEf17

What’s the result?  Programmers coming out of college aren’t used to anyone constructively picking apart their code.  Especially when you’re dealing with the top computer science students in the country.  Their code works, it’s fast, and in any college it would deserve an A.  They haven’t been trained to graciously defend their coding decisions when put under attack, it shows, and it’s not their fault.

When you’re not used to a teammate giving constructive criticism about your coding decisions, it takes a bit of getting used to.  The best actions a team can take are:

• Foster a community of critical-but-positive code reviews
• Make sure that everyone is reviewing, not just under review
• Build personal relationships at the same time that you’re reviewing code instead of just blindly criticizing someone else’s deeply-considered work

Code reviews are absolutely essential to a strong development team.  There’s a reason the top companies of all sizes rely on them.  The entire computer science education system needs to reconsider how students are naturalized into this process, and until then code review products and the teams that use them have to work hard to remove their social stigma.