If you ever work on a team I can't recommend code review enough. I can't comment on how useful it is to review your own code after the fact by reading it, but y

If you ever work on a team I can't recommend code review enough. I can't comment on how useful it is to review your own code after the fact by reading it, but you could certainly give it a try that way if you are currently working alone. Code Review requires two skills (one interpersonal, one technical): 1. How to read code (often in diff format) and run through it in your head to look for technical correctness. 1a) How to read code and look for style issues like code structure and variable/function naming. 2. How to write constructive feedback so that the author of the code feels happier after your review than before it. The best part of code review is that even in an environment that doesn't officially support it (e.g. no code review tool or source control, or an official policy against pre-commit/pre-merge reviews) you can easily do informal post-commit reviews. In my opinion the two major benefits are to decrease your bus-number, and to slow down the pace of code changes (at least if you have a pre-commit/pre-merge review policy). By decreasing your bus-number I mean that you force someone else to read and understand the code before it goes into "production". Even with half-hearted reviews this usually means you've got at least one other team-member who is can say "Oh yeah, I remember that $IMPORTANT_FEATURE was changed recently." And finally by slowing down the pace of code changes I mean that code spends an extra few hours/days sitting around, which gives more people a chance to look it and spot issues before releases. This is kind of a social hack, it stops from-the-hip code changes from immediately going into your codebase which increases the chances of the author or someone else giving them a sober second look.