It seems no one raises the point of what's in your company's best interest?
Often, if not always, programmers are just employees, and while the management decisions might frustrate us, we often do not have all of the data they do.
For example, say the company is contracted with a clause that if the software isn't ready in time, you won't get paid (it just happened to us, though I think we got the payment after all). Yeah, clean code is important, but more important is to have the code working by the payment day!
Another example - the company is in bad financial position and needs to raise some money. Guess who cares about quality? You can fix it later, if you have to, just ship it!
An argument might be "Why should I sell out and write crappy code?". Well, why should your company pay you a nice check each month? Choices, my friend. If you are after idealism, try the Free Software Foundation; I hear they're doing some pretty cool stuff (I mean this one, and I respect FSF and OSS).
On the other side of things, if you work on a project where an explosive growth in usage is expected (although such projections are almost never accurate), you better lay some solid foundation with the best code quality required, since it's almost certain maintenance will be the bigger cost for the project.
Programmers love 'clean' code, whatever that means. We can't even agree on what's clean, but we love it. However, sometimes it just doesn't matter that much as usability and correctness do. These might seem synonymous, but they aren't - if you've seen code written by a true Perl hacker in 4 hours with the intent to be used twice and thrown away, you would acknowledge it's not clean, but it works.
So sometimes, ego aside, we should just get it working. Note that I don't recommend writing bad code as a habit; I'm just pointing that it might be necessary. Perfection takes time your company might not have. So if your employer doesn't mind, craft software, but if you need to, just write working code, never mind the 'cleanliness'. It's just not a 'One size fits all' answer - you should prioritize.