Very apt given I was just moaning (zombie?) to my colleague about this. The problem is how you get your pride back though - especially when management continually gets in the way.
agreed - management is a key problem here. That extra 20 minutes to make your class readable, multiplied by 20 for all of your classes, is going to be very difficult to explain when your boss walks over to talk about why your project is overdue. There's an argument in there for time estimates to include refactoring, but that's a whole 'nother problem.
Management is a lame excuse, and you've just defined why: it's "going to be very difficult to explain".
Grow up, deal with it. Delivering bad news is part of many jobs, and programmers shouldn't expect to be exempt.
It's your choice whether or not you compromise your code. Sometimes you'll agree that it's worth it (shipping means $$$ the company desperately needs), sometimes saying no (because you know the consequences won't be worth it) will initially make people unhappy/disappointed/angry.
You can't please everyone all the time, and if you make pleasing your boss your highest priority, well, that's the price you pay.
That's a very naive viewpoint - if you present your boss with the reality of the situation, that you put off completing the project to rewrite code you've already written because you weren't happy with the results and have some vague idea that some future programmer might struggle to read it, s/he's going to look for someone who can deliver.
While you and I know that refactoring is the right thing to do, the customer/manager isn't going to say "by all means, delay completion of the project in pursuit of improvements to parts of the system that only you have to deal with". They don't see/understand the code so naturally they don't care about its state.
[note]
Obviously this is a blanket statement but it's been applicable to me and I'm sure others have experienced similar.
After a few years, you realize that if nobody wants your right thing, it isn't the right thing for business, and you have to decide if you want to resign and pursue your art with intellectual integrity, or keep working in the sausage factory that generates revenue.
If the guy who made my lunch sandwich put as much pride and care into his product as we all want to, which lasts about as long as the average modern software application, it would cost $50 and I wouldn't want to buy it.
> it would cost $50 and I wouldn't want to buy it.
I think that's a false dichotomy. There's the $6 Subway option and the hypothetical $50 perfectionist option, but you can also get a really amazing sandwich near here for $9. They make something they're proud of, and it costs more than Subway, but it's worth it.
Delivering bad news is part of many jobs, and programmers shouldn't expect to be exempt.
I agree that the typical Make-The-Boss-Go-Away Development Methodology is suboptimal. The only reason software engineers even come up with those silly estimates (which are pure bullshit, and lead to dashed expectations) is to make bosses go away so they can get back to work.
That pattern of behavior isn't what's best for companies.
On the other hand, this guy is a hired company cop that can turn off your income and fuck up your resume. You have no moral responsibility for anything but what works for you. If you have the rare good boss and a positive relationship, then deliver bad news early and be honest. If you have the typical extortionist thug ("serve my career goals or get out") then Make-The-Boss-Go-Away Development may not be the best strategy, but it's certainly morally acceptable.
