QA is important, but determining how many spaces a line of code is indented is not QA. That is a code review, which is important, but not critical. There should be automated acceptance tests, so that new releases can be shipped immediately. (It's also worth noting that stuff like indenting, naming conventions, etc. can be automatically checked at checkin time. See Perl::Critic, for example.)
If there is some feature or corner case that the users test but isn't in the acceptance test suite... well... yeah, the software is going to be unreliable. So don't do that. Write a test.
(I worked somewhere with a QA department once. They didn't like it when the programmers wrote tests, because they felt their job would be threatened. It was true, so we were asked to only write unit tests; no "integration" or "acceptance" tests. I quit a few weeks later.)
No developer should limit themselves to unit tests.
As an optional if the QA people are good then describe what else might be effected by the code (if you edited a generic component). Good QA people will run your test, work out their own variations and also check other areas.
At ThoughtWorks we work with QAs constantly. It's a great relationship. There's no such thing as "QA's bugs".
Any decision made that promotes inefficiencies to "save jobs" puts the entire company in danger.
No developer is good at testing their own code because deep down no developer wants to break the code they just lovingly crafted.
(In fact I just refactored this comment to fix a spelling mistake... but I published it without writing any automated tests, or running it by QA... somehow I don't think many people noticed)
I think people are responding to the suggestion that in general developers will subconsciously protect their ego by willfully ignoring flaws in their own software. That is just tremendously offensive to any real hacker, and if it were true the world of software would be a pale shadow of what it is today.
When a new bug is found (a good one, not BS indentation) then QA has a justifiable joy in finding it before it got to the customer. The developer may also be devoted to quality, but doesn't your heart sink a little when you see a new bug? Overall you both want to ship good product, but your minute-to-minute motivations are just different.
I'm not saying you're wrong, I'm just saying there's no hard rule on this. I've had to push code many many times without any outside testing and while occasionally it's been detrimental (but fixed quick, because I didn't have to go through QA), the large majority of times has been beneficial.
A large and formal QA process can kill a product / project just a quickly as cowboy code.
If the feature was really critical and important, QA should find a way to expedite the verification, but it should never be skipped in order to ship the fix faster.