Something I recently read helped me with this. The guy said “refactor often”. So I code the solution for the problem at hand and when something else touches it,

Something I recently read helped me with this. The guy said “refactor often”. So I code the solution for the problem at hand and when something else touches it, and a refactor is necessary, I do it right then, schedule implications be damned. Early on it can be a hellish bit of regressions, but after a time, the refactors move from less disruptive to smooth. And I get two bonuses: technical debt stays low, and analysis paralysis is optional. There’s a trade-off between time to completion and designing debt-free code, and I think that one small mantra helped me find the right balance. And let’s be realistic, the only debt-free code is code that is never touched by new implementation.