>>10Think of it like this: you decide that you want to make a quick and dirty version of your project, so you cut corners. You know you're not doing it the right way, and what you're doing might cause problems later down the road -- for extensibility, lack of documentation, bugs, etc. You skip spending 10 seconds to comment some obscure functions you wrote. You save some more time here and there by not doing things properly. In total, you end up "saving" 2 hours of development time.
But in doing so, you've given your future self 20 hours of debugging, re-reading (for undocumented code), and refactoring headaches. So really, it caused you to spend more time on the project, not less.
The way to avoid technical debt is to do things the right way to begin with. Easier said than done though. But practice makes perfect, and good habits will help.
When you're writing software, don't just concentrate on the here and now. Think: what will make this easier to use in the future? Commenting, self-documenting names, clean code, proper access modifiers, putting things into classes or functions whenever possible, doing testing before you notice any problems, modularizing things, and thinking about how to make something more easily extensible so that if, in the future, you want to add additional features, you don't have to redo everything. For right now, your project might involve doing A, B, and C. But once you've finished that, you might want to add features D, E, and F. But the way you wrote the first features can determine how hard it is to add more stuff onto it later.
And sometimes it helps to come up with UML diagrams, written paragraphs describing what you want your software to do, a Powerpoint or LibreOffice mockup of what you want it to look like, flow charts, and things like that. Authors don't write books cover to cover. They write an outline first. Do something similar with software. Requirements, avoiding scope creep, testing, wish lists, all sorts of things. If you're only working on your source files and not some sort of guideline along with it, you're doing it wrong.
Also: remember that it's easier to write code than it is to read it. So you want to document it well. Write a tutorial on how to use it, not just a couple comments here and there. But don't have way too many comments either! Whenever you change code, you have to change the comments as well. If you have too many comments, it might be more likely that you will forget to update them, and then your old/outdated comments will actually confuse you even more. You might think "why do I need to comment this, I know what it does" but people forget things. Our memory isn't perfect. I look back at my old undocumented code from early projects I made (before I knew any better), and I think "what the fuck does this even do?" and I'M the one who wrote it.
Think about the long-term, not the short term. When you're writing code, think: will I regret doing it this way in two months?
So you don't "reverse" technical debt. You just try to avoid it in the first place. Refactoring is what you have to do in response to technical debt.