I’ve never once seen “come back and fix with deadline” work. It’s really only the “with deadline” that does not work. Good teams will constantly be judging if now is the right time to fix the thing, and that fluid process works pretty well. Setting deadlines for tech debt just leads to the people setting the deadlines getting upset and quitting when they are inevitably missed. Save the urgency for when it’s warranted, like discovering a time bomb in the code, a scaling limit that is about to be breached— people will take you more seriously, you will be happier, they will be happier, hooray.
By all means, shoot for absolute perfection on your own projects. I work very, VERY differently on my own code than I do on work code, and I get different types of satisfaction out of both (though of course massively prefer working solo).
I’ve implemented APIs with routes like `/temp-get-order` in an attempt to force a return and even then we never returned to it. Like you’re saying it was eventually deemed insufficient for reasons outside of it being imperfect and that’s when we finally replaced it. Maybe places with more resources or discipline can manage otherwise but I’ve never worked somewhere that can.
That only works with product teams, in consulting it is either done alongside the ticket or it is gone forever, there isn't even any guarantee who will stay around after the delivery cycle is done.
And the new team might not even be allowed budget to fix those issues, and better not spend hours that do not fit tickets on the Excel budget plan.
By all means, shoot for absolute perfection on your own projects. I work very, VERY differently on my own code than I do on work code, and I get different types of satisfaction out of both (though of course massively prefer working solo).