The best way to find errors in your reasoning is to show your
reasoning to someone else and to accept objections as attempts to
debug your thinking.

Do *not* take this as a personal criticism.

Since this leads to a better line of reasoning, and usually to a
better product, you can think of this as a way to improve *you*.

---> egoless programming

If you use pair-programming, you get a continuous review of your
work.
 "Can't we test this, too?"
 "Shouldn't we take care of this strange case here?" 

For more formal occasions, you get team-level reviews: more eyes
spot more problems.
 - requirement review session (with customer)
 - design review (with team and requirement rep)
 - test suite review (in team)
 - code walk (in team again)

The key to all reviews is to inspect what is written down, and not
what you think. This is the *only* way to ensure that you can hand
over the project to others and with it your thinking about it.

Example 
----------------------------------------

The silly game

Also study the code example.