Every senior engineer I've ever worked with has strong opinions about technical debt. Most of those opinions are wrong — or at least incomplete. Technical debt, like financial debt, is a tool. The question is whether you're using it intentionally.
Intentional vs. accidental debt
Martin Fowler's technical debt quadrant is still the best framework: debt can be reckless or prudent, and deliberate or inadvertent. The only acceptable technical debt is prudent and deliberate — a conscious tradeoff with a known repayment plan.
Accidental debt is just bad engineering. You didn't choose to accrue it; you accrued it through ignorance, haste, or poor craftsmanship. That's not debt — that's damage.
When deliberate debt makes sense
Early-stage products: If you don't know whether the feature will survive the next quarter, over-engineering it is wasteful. Write the simplest thing that works. If it survives and scales, refactor then.
Time-to-market pressure: Getting to market two weeks earlier can be worth significant architectural debt — if the market opportunity is real and the debt is tracked and paid.
Validated assumptions: Build the hardcoded, manual version first. Automate when you've validated the assumption. Premature automation is one of the most expensive forms of technical debt.
The debt register
Every intentional debt decision should be recorded: what was the tradeoff, what's the cost of carrying it, and what's the trigger for repayment. We keep a debt register in Notion for every client project. When the trigger is hit — traffic threshold, team size, feature complexity — we plan the refactor.
The rule
Technical debt is fine. Untracked technical debt is not. Know what you owe.