RSS Feed

Latest Entries

Wednesday
May022012

What should a good code review look and feel like?

The way I see code reviews, is that they are a great cover for learning, mentoring _and_ finding interesting quality issues in your code. If our main goal as leaders is to grow our teams, then code reviews are a great way to grow team members, by helping them gain many skills: how to mentor others, how to communicate better, Not being shy about asking questions, stopping hoarding knowledge and much more.

You should leave a code review either feeling like you've learned something new, or that you've shared something new, or that you've caught something stupid, or too smart, and you're more proud of the codebase.

To achieve all these great benefits there are some important points you can't neglect:

 

  • To increase learning on many levels from each other, code reviews are always between at least two people (sometimes a third person can join in to learn how to review), sitting side by side. Not in different work stations, not in different offices and not in different buildings. Those learnings can be as simple as "how did you do that with the keyboard?" to "why would you even do that?" to "I didn't even imagine that's something you could do"
  • To increase code quality and remove the chance of forgetting to implement them, code review comments are taken care of either _during_ or right after the code review has ended
  • To increase focus and energy, code reviews should be short. 30 min. is almost too long. 5-15 min. is good. To do that you'll need to make sure that code reviews cover smaller parts of the codebase. One way to achieve that is by reviewing on every check-in, so that the batches to review are smaller.
  • To increase overall team proficiency and share knowledge, code reviews are done by all members of the team to all other members. At least, that's the long term goal (within 2 months it's possible to achieve for a team of 10).

 

If you want to get started with code reviews, and read how I'd recommend teaching everyone to review each other's code, I expand on those things here.

What about all those code review tools out there? I don't use them and never have. If you use them, you're missing out on the most important part of code reviews, the interaction with other people to learn and teach something. Remove that interaction, and you're left with a dead, boring feeling of having to look through someone else's list of boring things they think you got wrong. Who has time for that?

« Chapter four - commitment language - is online | Main | Do new startup leaders need to grow their teams? »

Reader Comments

There are no comments for this journal entry. To create a new comment, use the form below.

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Post:
 
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>