I write bugs. You write bugs. The customers generate bugs and we all look bad. For the most part, though, it's not the programmer's fault. CNN has an article about software disasters and it makes it pretty clear where the bulk of the problem is: bad management.
Alice the programmer creates a system that implements the spec handed to her by her boss. Because she didn't understand one of the lines of the spec, her software deletes cancelled products rather than marking them as "discontinued." Thus, the system starts to repeatedly fail as queries try to join on non-existent products and someone's failure to add foreign key constraints to the order_items table ensures that the problem is not caught right away. So Alice screwed up big time, right?
Well, possibly. Maybe Alice has been a dedicated employee for 10 years and rarely, if ever, produces buggy software. Sure, maybe a major product has a serious flaw that's not been caught, but the reality is, Bob the manager has a responsibility to ensure that programmers understand his specs. Bob has to make sure that QA has drawn up an acceptable test plan and fully implemented it. Bob has to know that a hard-drive failure on flight-control software doesn't kill everyone on the plane. Bob has to have confidence that customers will know how to use the software and that the software does what is planned.
Customers, of course, don't care, but managers need to understand that they are the ones responsible for the product. The programmers are only responsible for the piece they are working on. And if Alice keeps turning in bad code? It may not be Bob's fault, but it's Bob's responsibility. He has to figure out why Alice is turning in bad code. Is she sloppy? Are the specs clear? Is she not writing tests? Does she need more training? Is QA just missing things? (Side note: QA is Quality Assurance, not Quality Assessment! That's a common misperception which causes all sorts of problems.)
Software is a process. Sometimes the process is all rolled into one individual, but if you have a management team, they are there to manage the process. Sometimes programmers are bad and have to go, but management ultimately has to realize that sometimes programmers are great and the software is still rotten. When that happens, it's time to start figuring out what's wrong with the process.