Bring a group of senior business intelligence professionals or SQL Server pros together to review each others code and you have all the potential for a good knife fight.  As our team is getting ready to make design/code reviews a regular part of our development process we’re looking to make sure we get off on the right foot.  This led me to a great post by Ben Kamens of the Khan Academy.  Ben provides six tips for effective code reviews. Of those six there are a few in particular I want to make sure my team and I focus on:

1. Point Out The Good Stuff

If your team isn’t taking advantage of the chance to also acknowledge good work and the little sparks of genius that pop up here and there, you’re doing it wrong.

2. Review In A Timely Manner

Waiting a month to look at somebody’s code and then lobbing a bomb of critiques their way is a great way to really piss someone off. [Additionally,] this guarantees that the dev will have forgotten a lot of their work, and you’ll catch them on their heels.

3. Encourage Discussion During Review

Blindly accepting all of a reviewer’s suggested changes isn’t healthy.

Kamens wraps up his post with a prime piece of advice which I’ll be looking for my team to keep at the top of our agenda: “Code reviews exist to help your team refine its problem-solving abilities, not to produce the perfect block of code.”

(and of course if all else fails, it turns out “Knife Fighting Techniques From Folsom Prison” is available on Amazon.  Required reading for any SQL Server professional…)