Code Critiques
by Dave Tufts - June 26, 2007 / 5:56pm View more articles
Every Tuesday afternoon the developers at iMarc hold group meetings. We talk about such nerdily interesting topics as code standards, ways of indenting CSS, naming directories, frameworks, and any other programming issue that we deem worthy.
About six months ago we started holding code critiques. They've been really positive and educational. Here's what we do...
1. On Monday – sometime before lunch – one or two developers post a single page of their code on our Wiki. Maybe it's a snippet from a class, maybe it's part of a page, maybe it's a complete small class. We try to keep the code posting somewhere under 300 lines.
2. All the other developers download and review the code.
3. On Tuesday afternoon, during our weekly developer meeting, we look at, talk about, and critique the code snippets.
The intent is not for the developer to write of the perfect 300 lines of code or spend 4 hours finding the cleverest ternary condition they've ever written. Instead, they just pick anything that they want to get feedback on.
For those critiquing the code, they offer constructive criticism. If you're the person doing the critique, you also often find yourself thinking, "wow, that's a really neat way of doing that...."
Whether your getting critiqued or doing the critiquing, you tend to learn something with every review.
The idea sprang from design and photo critiques that I had to do in college. These typically included getting an assignment one week, then doing the assignment, hanging it on the wall, and letting the class rip into it the following week.
Our code critiques have been really helpful and constructive. If you work with two or more developers, I highly recommend trying code critiques.
About six months ago we started holding code critiques. They've been really positive and educational. Here's what we do...
1. On Monday – sometime before lunch – one or two developers post a single page of their code on our Wiki. Maybe it's a snippet from a class, maybe it's part of a page, maybe it's a complete small class. We try to keep the code posting somewhere under 300 lines.
2. All the other developers download and review the code.
3. On Tuesday afternoon, during our weekly developer meeting, we look at, talk about, and critique the code snippets.
The intent is not for the developer to write of the perfect 300 lines of code or spend 4 hours finding the cleverest ternary condition they've ever written. Instead, they just pick anything that they want to get feedback on.
For those critiquing the code, they offer constructive criticism. If you're the person doing the critique, you also often find yourself thinking, "wow, that's a really neat way of doing that...."
Whether your getting critiqued or doing the critiquing, you tend to learn something with every review.
The idea sprang from design and photo critiques that I had to do in college. These typically included getting an assignment one week, then doing the assignment, hanging it on the wall, and letting the class rip into it the following week.
Our code critiques have been really helpful and constructive. If you work with two or more developers, I highly recommend trying code critiques.
Comments have been turned off on this blog.
Read something more recent.
Statements and opinions expressed in this blog and any comments
made are the private opinions of the respective poster, and, as
such, iMarc LLC is neither responsible nor liable for such
content.
RSS
3 Comments
I believe that the effectiveness of both approaches comes from having multiple people look at each other code thus improving at once the code quality _and_ the skills of the developers.