> This feels like it's probably dependent on the culture in question. Writing tests, caring about readability and the long term sustainability of the codebase a

> This feels like it's probably dependent on the culture in question. Writing tests, caring about readability and the long term sustainability of the codebase and even managing the technical debt all can be the exceptions themselves in certain teams. I worked in a team that had great culture in this regard. Writing tests, code review, and refactoring were considered an inseparable part of every task; when you estimated the task, you estimated how much this all together would take. The task was considered complete when the comments in code review were fully addressed. This worked well while we had a manager who was not a developer. He asked for estimates, we gave them, we delivered a product in much higher quality than was typical in the company, he was happy. Then we got a manager who was also a part-time developer (for another team). And he started asking questions like: "Why did you guys estimate this task to take two days? I could write it in 20 lines of code, why should writing 20 lines of code take two days?" "Well, we also need to consider this, and then we need to write a unit test for this and a unit test for that, and..." "No guys, you don't. Do not overcomplicate things, just do the simplest thing that works." -- I don't know what happened with the project later, because gradually all the original team members have quit. So, there are ways to address technical debt, and some of them do not require involving the management in too much details, but you still need some minimal level of cooperation from the management; at least on the level of "if the results are consistently ok, I will not needlessly interfere with the details just because I can".