There is certainly real tech debt

It maybe tech debt depending on a lot of context, with old tech you get into a lot of situations like this: https://stackoverflow.com/questions/9318895/how-to-integrate... Sure, there is an answer to the question, it is a little messy, not too bad, do this 30 times and you have a disaster to maintain. Formerly popular is also a red flag, over time it will get harder to hire. Resources and documentation will go black.

This is a good one. I've seen (and probably made...) some refactor PRs where someone takes an old system and breaks it up into new conceptual chunks. Code reviewer comes in and they find the new code makes even less sense than the previous code. Of course it so happens that the reviewer already knew the old code, and so it's only natural that new code is less legible to them.

> Also 6: tech debt being another term for "code I personally do not understand," or "software written in a way different than I would write it." Sometimes it's quicker for me to implement a desired change on a code that was written long ago by someone who is no longer with us by re-writing that part of the code in the way I understand it, and then implementing the change, as opposed to trying to understand the code and implement the change in a way that aligns with it.

There is apparently a disconnect between refactoring, rewrites and green field development and maintenance and long term support. How often do developers who are quick to move to the next shiny thing held accountable for years after? How often do they ask the hard and boring "What if" questions? How much is empathy a driving factor in these decisions?

I'd argue code I don't understand is indeed tech debt. not sure what you were implying with your statement, but I sounded as if you disagree with the statement. undocumented code that no one knows is a serious tech debt issue. time should be taken to read it, understand it, and document it.

When Framework A is built nmaintained and therefore has known, unpatched security defects then migrating away is critical tech debt that needs to be prioritized. In my org frameworks are actually our largest source of tech debt issues. Example: Somebody years ago bet on Angular 1.x, migration to 2+ was deemed “a near-total rewrite” and postponed, so now I we have to rewrite in React or whatever flavor-of-the-month. The same happens with Java, .NET, and other backend frameworks.