Programming non-trivial things without bugs is very, very hard, and very often not cost-effective.

The combination of two bug-free pieces isn't necessarily bug-free. The glue code is where you typically end up with the subtle assumption and domain bugs.

What is the intention of 3rd party code? What is the *exact* intention of the code you wrote 6 weeks ago? You may have documentation. It may even be really good. It's unlikely to be 100% complete.

Error handling and modularity in and of themselves do nothing to reduce buggyness, though they may make it easier and faster to find the more obvious and often-occurring ones. They are good practice though, and I strongly recommend them.

Sometimes being naive isn't bad - it often makes you aspire to better than the status quo, which isn't a bad thing. However, many "bugs" aren't even programming errors, they are communication failures somewhere between the customer and the developer. What the customer wants, what the customer asks for, and what the customer actually needs are three different things.

A program that solves some of the problem now, even with bugs, is infinitely more valuable than a program that solves all of the problem (or more frequently, a small subset of the problem correctly) when it is too late. That goes back to the "cost effectiveness" - the solution that generates the most profit is the better one in a capitalist situation.
There are other situations, such as healthcare, or community projects (open source), where "cost" either doesn't factor or is subservient to other goals such as safety, but it's not the general case.
That still isn't a green light for cowboy coding, but if you're dead-set on bug-free you might find it hard to deliver.

So basically every project then?

I WANT my phone to phone home you insensitive clod!

And another possible hypothesis to test is that a pay cap will stop these jobs from attracting highly social manipulative psychopaths hell bent on just getting rich at the expense of everyone else, instead of actually running a company properly.

If you were responsible for the key, and lost the key, you might very well be liable for the damages caused by having lost the key. If it was Terry Childs' responsibility under a reasonable interpretation of the terms of his job contract to ensure continued access to the servers (and it seems that's along the lines of what the courts have now decided) then he was in violation of his employment contract for actually doing so.
It was potentially naive for the employer to trust him with this much power, but it's equally likely they had no technical idea that this was the case. The only other option beyond trusting your highly skilled employees is to have at least two people for every job, and then hope they don't actually collude to cause trouble anyway.

The contract doesn't magically disappear into thin air - it ends under the termination terms of the contract. Those are almost certain to state that you are required to return all property, physical or intellectual, that belongs to your employer and you were granted access to for the purpose of performing your role. The passwords are quite obviously important intellectual property of the employer. The "getting hit by a bus" case is irrelevant in this particular case (even though correct planning for it would have prevented Terry Childs from holding the passwords hostage) - Terry Childs wasn't killed and didn't disappear off the face of the earth, he was fired and was still required to follow the termination terms of his contract.

Um, dude.

If you think C++ is simple or intuitive you haven't used it enough, and/or enough of it. There is nearly always some dark corner of the standard that does something which is at first glance totally illogical until you understand the way the compiler or history has had to deal with the construct in question. The most vexing parse, for example, or the fact that there are three char types (char, unsigned char and signed char are distinct types).

Most "precisely engineered" stuff that's actually engineered is still the product of large quantities of trial and error, at some level :)

You can teach the facts of religion, in unbiased form, perfectly fine. I know this, because I've witnessed it, in a Catholic (!) school in the UK. They covered most major religions and the differences between them, without claiming any of them was right or wrong. No, Catholicism didn't get preferential treatment in that class. Faith and religion are important factors in most societies and covering them (correctly) in school is probably a good thing to ensure well-informed individuals.