> What's the biggest benefit you've gotten out of code
> reviews?

I have changed some of my coding habits. I'm talking about subtle mental habits that are responsible for how I think about problems and solutions.

In particular I always try to minimize state and when I do have some state I am more conscious of it. Another thing I'm more conscious of is code verbosity. I try to reduce LOC if I can.

That's not to say the code I write now is perfect, but in my experience it at least tends to be better (less buggy, shorter, easier to understand for myself and others) than something I might have written 5 years ago.

> What code review process has worked for you?

I prefer a highly informal "process" where the criticisms are very honest and not sugar-coated, and yet I still feel that it's friendly and playful. It has to be a two way process. People who would review my code can learn a thing or two themselves and are not really qualified to be an authority for me (or anyone else for that matter). So if I am really to take some suggestion to heart, it has to be discussed in an open, two-way manner, and I have to consent to a better way of doing things without any coercion, simply on the strength of the logic behind the argument. The management never knows about any of it and code reviews are not the basis of anything whatsoever, except my own personal improvement. For example, the code review is not a determinant of my salary, etc. That's the kind of code review that works best for me.

> What's the biggest benefit you've gotten out of code reviews?

I started to look for the bugs that I saw regularly in reviews *as I was coding*. Not including the bugs in the first place is easier and more efficient! ;-)

Lame discussion. A short audio interview about code reviews.

a. I would have spent less time reading this interview as an article then listening to the interview, but I guess writing it down takes effort, hence the audio.

b. Multiple techniques exist to code quality, like simply turning all the compiler warnings.

c. Finding bugs are not the only reason for code reviews.

Some reason include:
· Coaching: Many peer/code reviews deal with developers learning and applying technology (coaching). Modern tools look at code and provide insights into fixing code. For instances is a developer misusing the set/get feature in C#? Is a class in canonical form? Is the class missing hashCode, equals, and toString methods? Is the hashCode method properly implemented? In many instances, the tools do a better job of coaching than peer/code reviews.

· Knowledge transfer: I can think of dozens of examples where just showing my code, or just talking out load, has presented improvements. However, does code review have to be the point of knowledge transfer? I have gotten a great deal just out of informal conversations and whimsical white board drawings than any code review had produced. These are more peer conversations than reviews, and I consider more effective.

Real purpose of reviews
Once a developer knows that their code will be reviewed, the developer changes their psychological behavior to writing code. (This is true in every profession. Once someone knows they will be audited, people change behavior. The concept is even part of the judgment day in the Bible.) However, I don't like the approach. Why not setup measurements that will reflect on the strength of the code over time, not just the number of lines of code, or the elegance of design, but measurements that reflect reality of the business. Let the developer decide on the best processes based on their abilities, problem space, and technology. As General Patton said, "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity."