In the end, developers have to decide if they're professionals or not. Me, I think of myself like a doctor or a lawyer or an engineer. That means I have a code of ethics and professional duties. As an example, the IEEE/ACM software code of ethics is here: https://ethics.acm.org/code-of-ethics/software-engineering-c...
It's also reasonable if people think of themselves like a minion or a servant, where they're going to do what the boss says, no matter how dumb, dangerous, or counterproductive is. In which case, sure, they can excuse themselves from this discussion of how to manage tech debt, because they've decided to put that power in the hands of others.
But if they are professionals, then this indicates a good place to start:
> Why are you suggesting estimates that are 1.5x - 2x higher than the rest of the team?
Any improvement in working conditions is best achieved through collective action. That is a great moment to talk to team members about setting joint standards for estimates. And one doesn't have to approach it from a highfalutin' perspective of ethics. If colleagues lowball estimates out of ignorance or while seeking glory, that means they're just screwing over the rest of the people on their team.
Which leads me to this:
> those are the circumstances that they put up with to get food on the table
This week, sure. Not everybody can just walk out the door this moment. But over the next 5 years? Every single working developer can have a plan to get more autonomy and better working conditions. Including by building up enough of a cash buffer that they aren't one disagreement with the boss away from not being able to put food on the table.
Indeed, I think it's vital that they do. If they instead just bump along at a job with outdated tech and high debt levels, how easy do they think it will be to get jobs later in life? The skills and habits one builds while working in that sort of swamp don't look great in interviews.
I worked in a team that had great culture in this regard. Writing tests, code review, and refactoring were considered an inseparable part of every task; when you estimated the task, you estimated how much this all together would take. The task was considered complete when the comments in code review were fully addressed.
This worked well while we had a manager who was not a developer. He asked for estimates, we gave them, we delivered a product in much higher quality than was typical in the company, he was happy.
Then we got a manager who was also a part-time developer (for another team). And he started asking questions like: "Why did you guys estimate this task to take two days? I could write it in 20 lines of code, why should writing 20 lines of code take two days?" "Well, we also need to consider this, and then we need to write a unit test for this and a unit test for that, and..." "No guys, you don't. Do not overcomplicate things, just do the simplest thing that works." -- I don't know what happened with the project later, because gradually all the original team members have quit.
So, there are ways to address technical debt, and some of them do not require involving the management in too much details, but you still need some minimal level of cooperation from the management; at least on the level of "if the results are consistently ok, I will not needlessly interfere with the details just because I can".
This feels like it's probably dependent on the culture in question. Writing tests, caring about readability and the long term sustainability of the codebase and even managing the technical debt all can be the exceptions themselves in certain teams.
Sure, you can turn around and run for the hills, but for many there, those are the circumstances that they put up with to get food on the table, or work with for different reasons, so those circumstances shouldn't be ignored.
Ergo:
> a) refusing to put debt in to begin with
Management: "Hey, what is this ticket taking so long to complete? Can't you just develop the solution more quickly, without spending so much time on refactoring, planning or whatever it is that you do? Developer X did something similar faster just last week!"
> b) for any new work, including necessary cleanup of what you'll be touching in the estimates
Management: "Why are you suggesting estimates that are 1.5x - 2x higher than the rest of the team? Refactoring? Integration tests? Test data generation? Logging? Do you really think that those are necessary for this many tickets? Don't you want to reconsider your estimate, not to be the outlier? No? Okay, we'll just take the averaged estimate of them all."
Personally, i believe that developers should be trusted more and just care about the long term sustainability of what they're developing beyond their probably employment duration at the company (given how popular job hopping is nowadays), yet sadly that's not been the reality in my experience, probably because of prioritizing functionality and business value now, rather than stability and reliability later.