Bugs are *not* the developer's fault!

OK, some bugs are the developer's fault, but if you eliminate the n00bs and the idiots from the test demographic, then I stand by my statement.

OK, fine, we'll also eliminate syntactical errors (you are using syntax checking in your development environment, aren't you?  If you aren't, go away.).  But that pretty much is it.

I've used a plethora of languages and platforms - C, C++, erlang, java, objective-C, perl, python, ruby, and javascript (if you can call that a language.  And yes I'm joking.  Mostly.).  Its pretty much a best tool for the time and the place kind of existence, and AFAICRemember there has always been the persistent underlying frisson of fear, forever, around bugs/errors.  And they all share one commonality. Errors are, always and every-time, considered to be a fault on the part of the developer.

Pity you, the poor java developer.
You begin by writing defensively.
You absolutely infest your code with fun stuff like

if ( foo != null && foo.equals( "bar" ) )...

You make sure there are inner classes everywhere, and you draw all your mutexes out on the board.
You really, really understand the JVM, and have covered for all the idiocy associated with it (start-up memory, heap, etc.)
You have memorize the first twenty pages of results from Googling "How to write bug-free code"
And the system still crashes with a null-pointer exception.
And its your fault.

As jlouis puts it so eloquently,

The strong belief present in almost all other languages - that you by some mixture of sheer luck and all-knowing divination can forsee all kinds of trouble your program might end up in - is ... well ... kind of irresponsible.

At least in the world of perl, most people know that bad shit can happen, and take defensiveness to an almost pathological extreme, on top of which there is always the attitude of "oh well, its perl, thats why it crashed" (Hey, don't yell at me, I'm just telling you what I've seen).  But thats just hiding the problem - the implicit assumption in that statement being "If you'd written it in a real language..."

Seriously, whence this assumption that people can be perfect?  You don't have to be religious to know that this is simply not the case - just go through a few chapters of Dan Ariely's "Predictably Irrational" in case you doubt this.
Shit happens!.
And no amount of Coding Standards, Methodology, Xtreme Programming, and Training will ever prevent shit from happening.  It'll happen because of stuff you didn't expect, couldn't expect, would never expect. 
Shit...will...always...happen! 

And that brings us full circle, right back to erlang.  To quote jlouis again, when developing the erlang way,

You place (the bar when developing) somewhere such that you think you got all errors in the system. Then you test the system and you fix the few remaining errors that places the bar just right from the perspective of implementation time versus failure rates. Errors that occur from here on out are probably in the class of benign errors. They may occur, but they won't make the system fail. And they will have little impact. In other words, it is about controlling the risk of a fatal error. In Erlang an error usually has to penetrate through several layers of protection before it takes down the whole system and puts it into an unusable state. Because Erlang programs are built such that they can withstand the unforseen and well as the forseen.

 And that pretty much says it all.  Instead of dreaming the impossible dream, work on the assumption that shit will happen.  In fact, plan on it happening.  Its more realistic, and frankly, more efficient.