to filter input... again? Forgot to comment a method... again? With a list like that, a developer can actively hunt down those mistakes before calling for a review. This is known as the ego effect -- you know your code is about to be reviewed and you don't want to hear the reviewer saying "Aw man, you forgot to filter input again!" You want to be the rockstar, the ninja, the person who makes others say "Wow, that's actually a great solution". The ego effect is what will drive you to improve your code before others even have a chance to take a look at it. Peer code review means being reviewed by someone of equal or greater skill. As should be common sense, code review cannot work when a junior reviews a senior's code. The junior might notice some usual discrepancies, breaches of standard, typos, or even errors like input filtering, but will usually be unable to identify a bigger problem. This will often require the definition of a hierarchy by skill in the team if one is not already present. Less code with clear milestones means better reviews. Code should be reviewed only after a personal milestone has been reached, and these milestones should be small and should happen often. In object oriented programming this is especially important, but also especially doable. Finished a new component which extends an interface which ties into an adapter that's already been reviewed? Finally fixed a problem with a specific method that's