Points 1 and 2 can be a good thing, if you have the mental fortitude and cast-iron gullet to specialize in cleaning up other people's messes. There's a lot of money to be made that way. It doesn't tickle the artistic urge the same way greenfield development often can, but that's what creative hobbies are for - I write - and you can derive considerable satisfaction from the knowledge that you're bringing order from chaos, and being quite well paid and appreciated for it besides.
> if you have the mental fortitude and cast-iron gullet
> to specialize in cleaning up other people's messes.
> There's a lot of money to be made that way.
How does an individual or a consultancy go about finding these messes to be cleaned up? I feel reasonably-qualified to go in and take the necessary steps to get engineering projects back on track, but I'm not sure how you would get started doing that?
This is surprising and interesting... how do companies who do not value quality when the code is first written come to value quality later?
I'd expect a pattern where the original thrower-of-spaghetti-against-the-wall has left, and management assumes the later devs - who can't go as fast, or get more bugs because of the holy mess of the codebase - are just not as good as the first guy.
> how do companies who do not value quality when the code is first written come to value quality later?
Not for nothing is it said that the burned hand teaches best.
It also helps to avoid organizations where immediate management is nontechnical - not an absolute guarantee of sensible behavior, of course, but at the very least it's a good baseline to set. And it's hard for any manager, especially any manager accustomed to being on the hook and under the gun for the myriad problems with unmaintainable code, to get too upset when people start saying things like "wow, this is amazing, this never used to work before and now it does exactly what we need, thank you so much, you guys are awesome!"
