I have a closet in the basement where when I did the vinyl plank floor, I ran out so the planks don't quite go to the back of the closet all the way. Problem? Yes? A bit ugly? Yes. But in reality the problem is 100% of the time covered by boxes and anyway I can live a happy life in this house for decades and not be affected. That's 0% tech debt.
On the other hand if my gutters are clogged, there's interest on that because the longer I wait the costlier it will be to deal with since clogged gutters can lead to basement leaks or gutters themselves detaching. Or, if my stoop is broken, that's not just an eye sore but I keep tripping on it, the faster I fix it the sooner I stop tripping. That's a high-interest debt that should be fixed asap.
In engineering, a high-rate debt could be some architectural thing that slows down the development of every single feature. You want to quickly pause features to pay this down so everything can move faster. On the other hand, some file that you never touch having some shitty code or lots of TODOs may be a very low interest debt since in practice you never touch it or are otherwise not bothered by it other than knowing that it's ugly - like my closet floor.
Engineers make two mistakes around this - fixing zero-interest debt when there's more important things to do on one hand. On the other hand, when they say "oh, product management/leadership didn't sponsor our tech debt fixing" - it's often because we fail to articulate the real cost of that problem - explaining that it's high rate and how it's costing you.
I disagree. they simply don't care because from the top down, new shiny stuff gets attention, not keeping the old stuff going.
edit: I also wanted to add this, if I do convince them of its importance, MAKE NO MISTAKE, management will agree that work must be done but it has absolutely NO BEARING on having a positive job performance. I just convinced management of something important that I have to do that I will receive no benefit from - unless it goes wrong then I'll get reprimanded.
Important, in the context of a hierarchy-driven development team or company, is defined first by the best way to let money flow towards the company, and second by the people who are enabled by the hierarchy to make decisions about where to allocate resources to improve that inflow of capital. While persuading someone it's momentarily important to shift from what was going to be done to what you think should be done can be one way to acquire "career capital" (Newport) and maybe move towards it being your job to do so, it doesn't change what your current job is which is basically to consistently show up and do whatever those others decide is important, and to be ok with that; slow, mediocre, gradual progress and existence, which is perfectly fine if you have other part s of your life, which you should be spending more time on anyway. If new shiny stuff gets attention, then that's part of the dysfunction of the overall system (Meadows - Thinking in Systems)
When I was early in my stupid career as an developer, I made the idiotic mistake of trying to influence decisions regarding things that didn't matter to anyone else, like accessibility, usability, and when I failed to do so put in a lot of my own personal energy to do it right anyway. That was worthless, and I got depressed, fired, and ended up homeless for a while. Do what you're paid to do, and be realistic about what that is, until you're literally swatting people away who want to pay you to do it, then you can do it the right way. Never trust companies for any reason, and don't invest too much of yourself in them unless you can guarantee positivity will come your way if you do things beyond your standard deliverables.
yeah, assuming you get to that point before burnout or CBF kicks in. Or maybe you never do and just retire off of corporate. I imagine that exact mentality is why so many game dev programmers burn out and chase the money they deserve in others parts of tech.
My point was that the burnout lies in mismatched expectations, as well as working excessively, and yes I'd agree that's probably why game devs do that. There are better avenues for "passion" than your career unless you can trade the skills you've built up in your career for whatever you want to do for work.
Edit: Additionally, if in retrospect I just said yes to the most viable incarnation of whatever the corporate overlords wanted, and stopped caring earlier about the hypothetical implications of poor technical decisions (which I should have accepted sooner weren't a significant part of my job), then the work would have just maybe got done and whether it worked or not wouldn't necessarily be my concern, and I'd have more fuel in the tank to just keep getting better and moving somewhere else.