I always make sure I für understand what the problem is. This can lead to me having discussions of 2-3 h and the outcome is that we actually don't need it. Or that we reduce the scope to deliver on time.
I'm not aware of things I write which will not bite me back one way or the other if I'm doing it shitty and having development standards is not developing a rocket.
No one ever asked me why in particular something took 3 days. I don't explain to someone that I wrote unit tests and no manager told me not to write tests.
Did you ever got chewed out by a manager looking through your git commits and asking you why you wrote it as it is written?
If you accept technical debt it's the development teams fault.
And yes a not that clean feature, which is easy to refactor IF you touch it again is not technical debt.
Instead lern to talk back: "oh you promised our customer that this feature will be ready tomorrow? I'm seeing a big risk in this as there are still issues we haven't figured out, you might want to manage their expectation."
"Ah sry I can't work longer today I already have a reservation"
"On the weekend? Mh I booked a hotel already"
"How long this takes? Mh let's see (1 day guess + 100% risk + backupday) at least 3 days. I can get back to you in 2 days to give you an update."
"I can prioritize your new request but I will talk to x to tell him that his task will be delayed."
"Didn't you promise customer x feature y already? Should I stop working on y to start with your new request?"
But I will not build a sync feature and not having alerting if it fails.
I will not write nee Features and will not think about a proper index.
If you do it right and actually learn those things from an early point those things become obvious.
And yes there is also that believe that a bug in production costs 10x what it would cost to find while developing.
Yes I'm aware of the fallacy that a manager might praise you if you are fast and accepts bug as a common normal thing.