When you need to write software that works, you take a fscking course in Software Engineering. You learn what your code is doing and you make it work. I'm not saying it's "easy", but I don't believe it's "hard". I haven't been around enough to be sure, but I think they're pushing the "normal coders are frivilous twenty-something-year olds" line a bit hard.

You can make software work, but the reason it often doesn't is due to poor management and budget constraints. With the tech boom, perhaps people got used to too much, too quickly. Writing software takes time and money, and I get the impression that just doesn't happen nowadays. Apparently noone has the time to do proper requirements analysis, then follow this up with ERDs/DFDs.

You can write robust code, so long as you keep some things in mind. Heck, let's make that one thing: paranoia.
Never assume anything about the data that's coming in (and what happens to it once it's out of your hands). Which leads us to the next bit, which is being able to deal with ANY data that that does come in (or gets lost).

We have tools to help us do this. Maybe they're expensive, but you can use them, and they can assure you 100% (and show you the proofs!) that your code cannot fail, assuming the system behaves in a predictable manner (ie. CPU keeps running and code is read one line after the other, sorta thing).

Commenting: Removes ambiguity. The big bonus is obviously in a team environment. That way, John doesn't need to ask Jim what $xyz refers to. He already knows.