If an institution has sloppy habits, documentation of proper behavior is just the tip of the iceberg in effecting real change.
It’s true that Laszlo has a really good culture of striving for best practices and following reasonable guidelines. I think the number one thing that keeps us headed in the right direction is frequent code reviews.
1 – Spread the knowledge of the code base. If every check in has a code reviewer, there are always two people who have domain knowledge for fixing any bug.
2 – When you go over the code with someone else, you often see problems that you missed while coding. A code review forces you to review your own code.
3 – The code reviewer can help remind you about coding guidelines and best practices.
It’s easy to get code reviews started because of #1. If someone else reviews your code than you aren’t the only one responsible for it. This aspect appeals to just about every programmer. After people are used to doing code reviews, they usually start to see other benefits.
Interesting. We use code review in my organization and design review. We never have trouble getting people to actually *DO* design reviews and making them successful, but code reviews are harder to make happen.
They tend to happen late in the life of a largish block of code, which I know is part of our problem. Then everybody says “more javadoc, please” and sloughs off doing the real reading.
But if you *had* to check in, say on a feature by feature basis, and you had to do code review for each checkin, it would change the dynamic.
What’s the size of a checkin for your team? How much is a developer asked to review at a sitting? Can you talk about that? Would you mind? I’d love to see an analytical post about the cultural nuts and bolts of this and how you make it work, and I bet a lot of other people would too.
I think we have some good basics where I work for keeping code reviews from getting personal, but we’re not good at making sure they actually happen and making them a necessary event.
Odd to read this article 9 years later. These days I find pair programming more effective than pre-checkin code reviews. When solo work is needed/wanted for various (good) reasons, then I’m fond of the “pair integrations” when you work with someone else for at least a few hours to finish up or incrementally improve some part of the code you just wrote. It is much more active than a code review, which I believe is much more effective and certainly more fun.