As I stated in my last post, I've been reading up a bit on code reviews. I didn't touch on the last part of the book, which finishes with a discussion of Capability Maturity Model Integration, Team Software Process and Personal Software Process.

When I was at Crowe, I was a part of the review process to move from CMM level 1 to CMM level 2. For the most part, the ideas were good, but the implementation seemed overly documentation-intensive. Not that documentation is necessarily a bad thing, but there was so much administration that I didn't see how it could work and still allow us to be competitive.

Anyway, the part of the discussion that caught my attention was the idea of using a personal checklist, much like the checklist you'd use to perform a code review. In order for you to become a better developer, you need to know where you make mistakes. I could sit here and write out all of the ways I think I screw up, but that's just my gut speaking. It's not rooted in fact. The book's recommendation is that you should keep track of all of the mistakes you  make and categorize them. By making yourself aware of the types of mistakes you commonly make, you'll start to avoid making them, and then you can take that off your list. And until you fix that type of issue, you'll at least be aware of it, so as you review your own code, you can look for it.

I think I'll start trying to do this - just a very quick and dirty list, and at the end of the day, I'll categorize them. By making them visible, hopefully I'll start thinking about them as I write code. At the very least, it'll give me something to look at as I review my own code before I check it in.

Of course, that's another benefit of keeping a personal checklist - if you're doing code reviews, you can (and should) share that with your reviewers, because it gives them something to focus on - specific types of mistakes that you know you commonly make. Remember, it's not a bad thing for your team to know your weaknesses. Ultimately, you share the same goal - build the highest quality software possible. It's in the best interest of the whole team to help each other improve, and the best way to do that is to know where you need to improve. And in the mean time, it's good to have someone else looking over your shoulder.

Tags: Code Reviews