[a13o]

The term 'technical debt' is conversationally bankrupt. Every possible programming anxiety is technical debt. Don't understand the system, the historical constraints, or the business objectives when it was written? Slap a 'technical debt' sticker on it and now you're the smartest person in the room again.

If you want to be an effective roadmap participant, learn to phrase technical problems in terms of immediate benefit to customers. It can then at least be prioritized against the reams of other immediate customer benefit ideas in the backlog.

If you want to marshal an impressive development cadence, focus far upstream of 'technical debt'. Whatever that term means to you, it's a lagging indicator. The solution is procedural, not technical.

[yarekt]

This, 1000%. I’ve never had any luck with figuring out a way to get management on board with tech debt, and this is a nimble startup with smart people… solution is elsewhere, not “write more quality software” near the symptoms.

[nextworddev]

Your comment is refreshingly honest and cutting to the gist of things. Wish I had more colleagues like you.

[000ooo000]

This dismissal of 'tech debt' as a phrase/concept based on weak strawman examples is just a contrarian rant followed by LinkedIn-esque advice that seems ignorant of the fact that hyper focus on 'immediate benefit' is almost always the cause of.. the technical problems that should be phrased in terms of their immediate benefit, or something.

[uuddlrlrbaba]

Hi, it looks like you're writing a reply. Try using sentences

-Clippy