Creating manageable technical debt

Creating technical debt is sometimes unavoidable. Maybe time is running short, or the problem is inherent messy. Or maybe, you're just exhausted. In any case, you have accepted that you will implement the unideal solution. In Martin Fowler's technical debt quadrant, it means you fall north of the "deliberate" parallel.
In my opinion, in this situation the best engineers will budget some of their limited time and energy to be considerate to future engineers. As with any other code or process, the demands of the future on technical debt will fit into these categories: And most true of technical debt,
Since the demands made on technical debt are no different than the demands made on anything else, it follows that the rubric for "good technical debt" has a lot in common with the rubric for "good contribution". To me, "good" technical debt is
The first criterion "keep it self-contained" I consider to be the most important because, honestly, some of us are just not very good at explaining ourselves. If there is at least a clear beginning and end to the technical debt, and it is clear how it interfaces with the rest of the code, it can be excised later, and care can be taken in the meanwhile to not allow it to extend its borders.