1. The reviewee should self-review his code before he calls you over - that means going over changed files and undo&#x27;ing those that are unneeded (i.e. where only a newline&#x2F;space was entered). They should also read through their changes in the diff window, and add in any comments where the &#x27;why&#x27; is not clear from the code.<p>2. There should already be a window open displaying how their changes affects the UI&#x2F;behaviour of your product, so that you can immediately get into the right context&#x2F;mindset when you come over. This way as they explain their changes you can compare with your mental model of how&#x27;d you&#x27;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)<p>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!<p>4. Once you&#x27;ve reviewed a team member a number of times you&#x27;ll find that they &#x27;get it&#x27; 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.<p>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 :\