The Effective Engineer[0] has a chapter on technical debt, where he goes into how a lot of crappy code decisions are there for a reason, and how rewrites can be

The Effective Engineer[0] has a chapter on technical debt, where he goes into how a lot of crappy code decisions are there for a reason, and how rewrites can be chaotic. If you have the time, I'd recommend giving it a read. I frankly got a lot more pragmatic about asking for rewrites after reading it, and I feel it helped me to grow (mature?) as a developer. Either way, I think there's a need to balance the need for employee self actualization needs which they often push as rewrite requests "Oh since we're rewriting this, we should (do it in)/use/etc X instead". I have often realized that a lot of requests to rewrite something are really tinkering desires camouflaged as a business related request, which is not to say that the code that does exist could have problems, it could, but having a period of debt repayment would improve it as well. So finding a way to allow your employees to tinker without letting their desires torpedo your products would be positive. Either way, it's a complex subject, and I don't really think there's a single "right" response to it. Best of luck! 0: https://www.amazon.com/Effective-Engineer-Engineering-Disproportionate-Meaningful/dp/0996128107 https://www.amazon.com/Effective-Engineer-Engineering-Dispro... EDIT: I'm not a CTO, I'm a developer.