You should not underestimate the power of leveraging the type system to prevent programmer error.
Do not think of the type system as a nanny. Instead, think of it as an integral language tool designed for your use. Use this tool -- the type system -- to convince the compiler enforce code correctness. Using the type system in this way will allow you to spend less time writing tests, as compilation can validate correctness.
If this seems unlikely, spend time with a language with a powerful type system -- such as OCaml, Haskell, Scala or F#. You will find that it is possible to implement equally succinct and considerably more correct code through leveraging language features -- including the type system.
Additionally, this exercise is fundamentally applicable with the real world. Should you use F# or Scala, you will find a vast trove of existing libraries, and high-quality, high-performance VM implementations at your fingertips. Your correct code, written faster, will run faster.
Uh, the techniques he describes are how you write better code faster in the first place.
There's no magic "better code" fairy that comes along and instantly makes you a master programmer. You get better by deliberately seeking out ways in which you're failing, and then correcting them. And you use the techniques the article describes - code reviews, assertion, unit tests, and static typing - to do that.
Eventually, those techniques become internalized, so that you still do them even when you take away the crutch of language and programming environment.
Notice how studies of master Smalltalk and Erlang programmers found that they just don't make type errors, and that when you add a static type checker to those languages, existing programs pass unmodified? A lot of people have taken this as evidence that static typing isn't necessary. But there's another interpretation: master programmers write their programs as if they were statically-typed, even if the language itself does not require or enforce this. The reason they can get away with fast-and-loose programming languages is because they've already disciplined themselves into automatically doing what the strict programming languages enforce.
And anecdotally, the vast body of crappy PHP and JavaScript code seems to support this interpretation.
EDIT: Hooray for searchyc:
1. Compile time checking can't catch most non-trivial bugs. Even if you swear by it, given the advances in Java IDEs, I would have to be quite lazy (or careless) to write Java code that doesn't compile.
2. Programming assertions - really? That's what unit testing is for. I like his point about being a testing masochist, but it doesn't sound like he's going about it the right way.
3. Having other programmers inspect your code can be helpful, but to me it's a luxury that you often can't afford.
"If I could bring this kind of a system to fruition, meeting all its requirements and budget and schedule constraints, just by conscientiously applying a slew of techniques for uncovering my programming failings before they got into the final product, then I knew that I would be able to fake it for the rest of my career."
The author claims his techniques have allowed him to create a good end-product, but at what cost? I could 'fake it' for the rest of my career, or I could invest more effort in learning how to write better code faster in the first place.