Don’t be afraid of Technical Debt

Developers usually aim to keep technical debt as low as possible when building software—some even shoot for “zero” technical debt. However, it’s important to remember that technical debt is an inevitable part of the journey. Every piece of code you write, in some way, is technical debt. Understanding this can help you manage it wisely and reduce anxiety about it accumulating over time.

But here’s the thing: achieving zero technical debt isn’t actually possible. Why? Because every piece of code you write is, in some way, technical debt. Yup, every single line.

Let’s start with the idea of personal growth

When you have 20 years of experience, you’re halfway through your journey. So, what’s next? Do you stick with the same methods you’ve been using, or do you keep pushing yourself to learn and grow? Do you keep striving to improve?

I’ve encountered developers with 20 years of experience who are only slightly better than interns. On the other hand, I’ve met developers with 20 years of experience who are absolutely incredible.

There’s such a big gap between different types of developers because of how fast our field evolves. Technology changes quickly. About 30-40 years ago, developers were concerned with saving just 4 bytes of data and might have spent days or weeks figuring out how to do it.

But today, that effort is pointless for most software projects. Computers are way faster and have tons more memory than they used to. While efficiency still matters, it’s not as crucial back then. Nowadays, we’ve got enough computing power to trade a bit of efficiency for things like better user experiences or faster development.

When you’re focusing on optimising for user experience or development speed, how you design your software needs to differ from when you’re optimising for execution speed. Even if the original code was expertly written with speed in mind, it can be tough to rework it for other priorities. That code becomes less effective because it no longer serves the purpose you need it to. In a sense, it turns into technical debt, even though it was top-notch when it was first written.

Those developers now have to adapt and learn how to write code differently. If they don’t, they might only excel at writing code for a no longer relevant purpose.

Take, for example, the decision to build something yourself or use an existing solution. Twenty years ago, fewer libraries, frameworks, or tools were available. If you wanted to get something done, you often had no choice but to build it yourself because there simply weren’t other options.

Knowing how to write code is one thing, but knowing how to evaluate someone else’s software is a completely different skill. Nowadays, there are so many options for leveraging software that someone else has already built. These tools usually come with dedicated teams behind them, which means they’ve probably done a much better job building it than you or I could if we tried to create it from scratch.

You’d have to be either a genius or a little bit crazy to want to build something that isn’t a core part of your business when there’s already a solution out there. The tricky part is that many options are often available, and figuring out which one to use can feel overwhelming. Writing code can feel more straightforward than trying to sort through all the choices, so it’s no surprise that many developers lean towards building everything themselves.

But here’s the thing—that can lead to bad decisions. Even if those developers did a fantastic job building things on their own 20 years ago, doing the same thing today often results in less-than-ideal solutions. And what code was used for their custom-built solution back then? It’s now using an outdated, inferior solution. It doesn’t matter that it was the best option then—there are better options now. That old code becomes suboptimal, which means it becomes technical debt.

So, what does all this mean for you?

It means technical debt isn’t something to be feared or avoided at all costs—it’s an inevitable part of the journey. The key is recognising it, managing it wisely, and pushing forward. Whether it’s code, skills, or mindset, staying adaptable and open to learning is the secret sauce that keeps you from getting stuck in the past. After all, the best developers are the ones who never stop evolving and who see every piece of code as a stepping stone rather than a final destination. So, embrace the journey, keep learning, and remember that every line of code you write today is one step closer to being even better tomorrow.

Article by Dave Fuller