What sort of problems are you trying to catch? Niggling little bugs or major design flaws? Both? Code reviews, as this brutal group process done after the cod

What sort of problems are you trying to catch? Niggling little bugs or major design flaws? Both? Code reviews, as this brutal group process done after the code is committed, are wrong IMO. It's better to talk out the design before any code is written, or circulate a design note. (Not a full design document; the only good design docs are written after the code.) As for catching the niggling little bugs, or generally improving your approach in the small, pair programming and check-in review work well. Check-in review is simply a convention that someone else has to read your diff before it's checked into the repo. You can make that an informal or formal part of your check-in process. It works really well; not only does it catch mistakes but it puts the incentive on the reviewee to write readable code, so they won't have their colleague complaining they don't understand what's going on. That may sound like a lot of work but it's not. Once everyone gets to the point where they know how to write readable code, the check-in review takes just a few minutes out of each developer's day.