Part of being personally and solely responsible for my products has been learning that a product is finished when it gets paid for, not when it leaves my desk.
When a programmer is pushed based on "When is this module going to be ready to be tested"", the primary goal is to get the product to the testers, and damn the maintainability, damn the little glitches, damn the quality, it does substantially what was requested and the testing department got it. It's off my desk. In the real world, things cannot work this way.
When people talk about introducing TQM or the philosophies of W. Edwards Deming (Or even Brooks' "Mythical Man Month") to programming, they often complain about the amount of data that people suggest collecting. "What?", you'll hear them scream, "Consider compile time errors to be errors? Why, I'll look like a fool."
The point is that errors, yes, even bugs in the final software, are more indications of problems in the process than underlying failures in the programmer. Sure, different people have different programming abilities, but if a coder is consistently making errors, even compile time errors, there is a problem that needs to be fixed.
When was the last time your compile failed because of a typo? Perhaps you capitalized a letter in a variable name? Rather than blaming clumsy fingers, or a sticky shift key, how about thinking in terms of revamping your naming scheme to accommodate the problem? Maybe you need to remove those underscores, since they require both a shift and the right hand to leave the home row?
Or are you constantly calling a function in a way that doesn't match the prototype or having to look up the parameters? I've found that some shops impose rules on the programmers that make them return an error code from every function, passing pointers to return values instead. My humble opinion is that these folks would save months of time if they'd let the programmer return a valid pointer or "NULL" from their allocation function and therefore have to worry about one less of the 4 or 5(!) arguments to the allocation function.
How about finding that mismatched opening brace in your C code? Maybe it's time to look beyond the indenting style imposed by book editors too cheap to allow for adequate whitespace in example code.
Different people work different ways, as do different teams. Rather than suggest a dogma ("GOTOs considered harmful"), I'd like to see what works out if we're all willing to stick to tradition a little less and get pragmatic for a little while we may be able to do wonderful things.