There seems to be two schools of thought about software quality:
School #1: If you write code that is difficult to maintain and/or test or is yucky in some other way, you suck as a programmer, and should be hung from your toenails to die.
School #2: The only thing that really matters is: does your code work? If it doesn't, you suck as a programmer (see school 1).
I think there are a lot of people in school #1 who think that anyone who has ever written crap code doesn't have any professional standards and doesn't care about the quality of the work they do. And I'll admit, if I thought a programmer didn't care, I wouldn't want them on my team either.
The problem is that it isn't that black and white. I don't set out to write bad code. Sometimes I just can't find a better solution to a problem. Or I'm up against a hard deadline. Or I didn't know there was a better way.
Lots of times I look at code I wrote a year ago and think "What was I thinking? There is a much better way to do this." Software development is a journey of learning. I'm never going to be perfect, but I am always getting better.
Davy Brion and JP Hamilton have each written some great posts about how this can happen, and admit they sometimes write crappy code too.
We shouldn't forget about school #2. In the end, most customers and end-users only care about if the code works. But educating them can help them to see that good code quality is more than just "does it work". Clean, easily maintainable code provides a long term benefit to non-coders in quicker iterations and cheaper modifications.