1. The reviewee should self-review his code before he calls you over - that means going over changed files and undo'ing those that are unneeded (i.e. where only

1. The reviewee should self-review his code before he calls you over - that means going over changed files and undo'ing those that are unneeded (i.e. where only a newline/space was entered). They should also read through their changes in the diff window, and add in any comments where the 'why' is not clear from the code. 2. There should already be a window open displaying how their changes affects the UI/behaviour of your product, so that you can immediately get into the right context/mindset when you come over. This way as they explain their changes you can compare with your mental model of how'd you'd have solved the problem, and notice any glaring problems along the way (like if they used a bunch of complex logic to parse a string when they should have used a simple regex) 3. Coders should expect to get reviews every one or two days, otherwise they will build up a substantial amount of changes that will take longer to process. Additionally they may even forget why they made earlier changes! 4. Once you've reviewed a team member a number of times you'll find that they 'get it' and have already predicted your questions and made the necessary changes. They are then ready to become a reviewer as well to lighten the load on you. 5. Post commit reviews do not work. The damage is already done by then. They tried this at a place I used to work and nobody learnt anything from it :\