> >  Contrast this method with the more common approach where once the
> >  program is coded, the engineer immediately tries to compile it.  The
> >  compiler then leads the engineer by the nose from one problem to the
> >  next.  When the program finally compiles, the engineer is so relieved
> >  that the immediate desire is to see if it will run.  One of the best
> >  clues that a shop follows this approach is complaints about how slow the
> >  compilers are."
> >
> >                                -- Watts S. Humphrey
> >                                   A Discipline for Software Engineering

On the other hand, ....

I make lots of fat-fingered* typos.  Half of them I catch myself before I
get to the next line.  The other half, I just can't for some reason see
them until either a couple of days have elapsed or the compiler points
them out.  Now if I were to discipline myself to not touch the compiler
until after peer review, I would be wasting the time of all the
reviewers.  Plus probably missing some "real" defects because the
reviewers are distracted by all the nits.  (I say "real" because a program
that won't compile can't crash the system.)

It is counter-productive to stare at a printout or screen for twenty
minutes and see nothing wrong, when a compiler can tell you in twenty
seconds that you have an apostrophe where you need a semicolon, or an
extra parenthesis, or ....

But as soon as (or even before) all the typos are fixed, a genuine review
would certainly be a good thing.

* you can call 'em fat-headed if you want, I'm think-skinned (or
  thick-headed)  :-)