The First 10 Seconds is the Most Important

I really enjoyed 10 Second Code Review.

If you fail to hold code reviews, the crappy code that works its way into your production code base really is riddled with obvious bugs.

A full review definitely takes more than ten seconds, but maybe the first ten seconds are the most important. If you don’t have time for a complete review, at least ask a peer to drop by and give your code a quick look.

Code Reviews

Mario and Mike posted their thoughts on code reviews, so I figured we should turn this into a full blown meme.

Have the Review

This is the most important step — far too much code sneaks through without any sort of review. If you know a code review is coming, I guarantee you will spend more time cleaning up your code.

Don’t be too Formal

One of the first projects I worked on many years ago had a formal code review process. We had specific forms to fill out, and huge lists of categories for things like “type of issue”. There were far too many choices, so nobody ever knew what to pick. In the end, having too many choices led to useless data. Plus, we all dreaded code reviews.

See it Run

I always ask the programmer to show the feature in action before we see the code, so we all understand what we are reviewing.

Break It

I try really hard to find ways to make the code fail. I’d rather find errors now than after deployment.

Avoid Duplication / Learn from Others

Without reviews, programmers work in relative isolation from each other. As a result:

  • They don’t learn from their peers, because they may not be aware of other approaches to similar problems in the code base
  • Code is duplicated, for the same reason

Having routine reviews is the best way I know of to ensure programmers really see and learn from each other’s code, and avoid writing the same thing over and over again.


If I can think of ways to simplify code, I’ll offer those suggestions in a code review. Try to imagine looking at this code a year from now without the original programmer present. Like it or not, each line of today’s code will become tomorrow’s legacy code.

One Problem with HTML Video

The HTML 5 video element is a move in the right direction, but it currently doesn’t work in Google Reader. Here is how a YouTube video looks in Reader:

This is on a Mac, using Firefox 3.5. Here is a blog containing the new HTML 5 video tag:

When I go to that blog, it works…just not in Reader.

Firefox 3.5 and the Beach Ball

I’m using Firefox 3.5 on Leopard, and noticing several slowdowns.

When we say Firefox 3.5 is fast, we mean it sometimes slows down. And by “sometimes slows down”, we mean the spinning beach ball of death.

Here are two cases where I see problems.

First, I see a severe slowdown in the search field. The slowdown occurs when I type a few characters and then hit the “:” key. For instance, try searching for “Bitter:Sweet”. Who knows if this is an Amazon or a Firefox problem. I just know it is slow.

The second slowdown was far worse. It occurred as I was creating my previous blog post. Ironically, I wanted to include a link to the HTML 5 specification. So in my first tab I had my blog open, and in the second tab I had the HTML 5 specification open.

I found the section on HTML video, selected the URL, and copied to the clipboard. When I returned to my blog page, Firefox completely locked up and I saw the spinning beach ball of death. I had to kill the process to regain control.

I repeated the above steps, and once again it completely locked up.

I finally managed to create that post, but only without the HTML 5 spec page open. So just now, while typing the previous paragraph, I again opened this URL.

And once again, Firefox became completely unresponsive, showing the beach ball for about 15-30 seconds.

It is mildly amusing that the one page that consistently brings Firefox 3.5 to its knees is the HTML 5 specification page.