[davidsiems]

The first company I worked for had mandatory code reviews, I was on a team of about 20 other programmers and I thought it was a great system.

Then I went and worked for a startup video game company, the programming team was myself and one of my friends from college. We decided not to do code reviews because we were building a game engine from scratch and the churn was going to be way too high to keep up with.

You can claim that code reviews are fast, but when you're generating a couple hundred new lines of code a day that really builds up. Especially when each person is committing 5-10 times a day.

What we decided to do instead is go down to the coffee shop below our office every day and just talk about what we were working on, the problems we had run into, and what should be worked on next. As a result, we still had a lot of knowledge sharing going on without having to look at every single line of code going into the codebase.

Having a general idea of how the systems are being built and put together is _much much_ more important than going over every line of code looking for bugs.

My point, is that the knowledge sharing is what's important. We could have done code reviews, but it was actually a lot easier to just talk to each other for an hour or so a day away from the computers about the state of the project. As a hidden bonus, we also got fresh perspective on implementation ideas before any work was done, which I imagine saved countless hours.

This sort of thing is probably less feasible at larger companies, so maybe code reviews are the best way to share knowledge there, but if you're under 3-4 people I'd definitely try this approach instead.

[aaronblohowiak]

There are different levels of scrutiny that you can Perform in code review; rubber stamping is useless, but you can do it quickly where the code is referenced during the kind of explanation i think you are talking about. Using git, you can commit locally and then push to origin after review (so you don't block on the other Programmer.)

[mkjones]

> My point, is that the knowledge sharing is what's important.

Definitely agree, though I think it's more than just knowledge sharing - I find it nice to know that you're "accountable" to some degree when you're writing code. Someone else is probably going to have to read it at some point (whether you do formal review or not), and making that fact explicit further drives home the importance of that last 10% effort to write quality code.

I think what I've found most useful about code review (pre-commit or otherwise) is a good way to have discussions with someone in the context of the code itself. Maybe this makes less of a difference in the super early stages of a project (though I've found it pretty useful then as well), but as your changes are increasingly modifications to existing complex systems, having the surrounding context in a discussion is really helpful.