> Unfortunately that's not true. If "shitty code that works" requires three days to be understood in order to make a small change that became a delivery issue a

> Unfortunately that's not true. If "shitty code that works" requires three days to be understood in order to make a small change that became a delivery issue and three days in a problem that can be solved in one hour are $$ that somebody is paying. In addition "shitty code that works" most of the time has scalability and performance issues sooner or later you need to address if you don't want it to implode. I think you might be missing their point. From the perspective of a programmer, yes, these things are true. Code SHOULD be Good and Right™, and that is very easy to see and grok from a programmer's standpoint. But to a manager? These things usually have to be stated explicitly, and that isn't entirely the manager's fault. It is easy and pervasive in the industry to write crappy code that works for a variety of reasons (time constraints, incompetence, poor decisions from on high, etc...). Even the best managers have some degree of "out of sight, out of mind" because they rightly delegate the responsibility of making sure the code works AND minimizes tech debt to the developer. It doesn't become apparent to them (and by proxy, the business) that the code was poorly written until the shit hits the fan. Also, it is unfortunate that you have to leave that job. In my experience in the industry, being able to go back and fix tech debt like you are describing is very uncommon.