I am dealing with a set of legacy apps that will eventually be phased out. There are 'generations' of code, trying to solve architectural problems that are never taken to completion. Making large moves like that is a form of technical debt; not taking every step through to completion (like, documenting the code ...) is another form of debt.
The original architect was, despite his outward appearance towards emphasizing correctness, was really not a great developer or a good technical lead. He insisted on writing "perfect" code, ignoring the rest of the development cycle or the people he worked with. Regardless, he left for reasons I am not really aware of last year. I knew he hated me, since I didn't share his obsession.
Fast forward to today ... the applications work. There is no more feature plans for it. But, it is frustrating to go back into it because the code is utter garbage. I am the only one who has any deep understanding of it in my company. Those who tried to understand it also struggled over it.
We are taking technical debt in the new application we are working on, but, we have been planning for it to happen. I have the chance with the devs I am working with to get this "right".
Throughout my career, the sense that I got was that people did not understand something critical: Owning code is a full-time job even after it is written. I never worked with technical leads that asserted that. They always made passing nods to the idea that we should comment more code or write more tests, as if it is just some tired dogma to follow, but no one has made a case to me for being clear on knowing what you are accomplishing, how one accomplishes it, planning to own the explanation of what the code does and what trade-offs were made and a plan to pay back the debt that was taken out. As tech lead now, I am continually communicating this; the progress is starting to show. I am just glad now my company is recognizing these needs too and is understanding the investment that comes with maintaining their major product.