Good, Fast, Cheap - pick any two.
So, what would you pick?

Like most programmers (I hope), I would prefer writing good code over bad code, regardless of how long it takes or how much it costs. But that's an idealistic view; the realistic answer for me is, "It depends."

I view all three characteristics as part of the overall Quality of the job, and the emphasis to give each depends on the requirements you're trying to fulfill. If the customer won't pay more than $X, then technically better code that costs more is not, overall, a good solution. And even if it means maintenance headaches down the road, should you turn out quick-and-dirty code if it makes the difference for a crucial sale that saves your and your co-worker's jobs? I would.

But that's not necessarily how everyone feels about it, of course. The key is knowing whether your priorities mesh with those of the project you're working on. No one set of priorities is objectively "better" than the other, and you'll find companies with all sorts of different philosophies. Given the demand for software professionals, you can most likely afford to be a little choosy and find a place that's a good fit. It's certainly much less disruptive to find it out early, (during the interview process, say) and avoid the kind of bad fit it sounds like you're dealing with, jeffa, but that's often easier said than done.

If there's a silver lining here, it's that this has given you an opportunity to really figure out where your own priorities are, which can only help in the future. It sounds like you're the sort who knows how to learn from the experience and land on your feet. Best of luck.