Totally, 100% agreed. Sure, there are a lot of developers who don't care about quality. Usually, they don't care because they're here to do their job and get paid, not to make an art piece. Which is to say, they would care if it was a part of their job, but it isn't, because of business-level decisions.
> there are a lot of developers who don't care about quality
And the underlying meta problem is that the people who are supposed to be responsible for figuring out which is which haven't got the faintest idea how to tell. Compound this with the fact that most management structures are still based on factory-assembly floor management where figuring out who wasn't turning the lever as fast as they guy next to him was the most important metric and you end up with corporate structures where trying to figure out which developers are better than which other developers actually has the opposite effect than the one they want.
This is going to sound defensive, but: is the problem really with developers?
In my experience as a developer, we've never been given the necessary resources (time, QA access, specs that don't change every day, sample data, redundant hardware, etc) to build a reliable system. Managers always pushed me to have something that looks mostly-working, and shipped by the artificial deadline, and argue that any known bugs or limitations are not important enough to fix before the next round of new features.
It's not so much that I'm not required to care, but that I'm not allowed to care. I get better food at Canlis than McD's, too, but given the time/ingredient/recipe constraints, even the Canlis chef would struggle to make something great if thrown into a McD's kitchen.
