How to Keep Your Developers from Idling in Tech Debt

Developers want to work on meaningful projects. They also want autonomy and work-life balance, along with using the best languages, frameworks and tools. Without these basics, you can’t attract the quality of talent you need on your team.

Hiring great developers without proper tools is like having a pro race car driver on a tricycle. However, developer productivity is more than just giving them the fastest possible cars to drive. It’s also about the roads you’re asking them to drive on. Technical debt is like potholes in your development process: the ugliest parts and unfinished business of all of your codebases and the various obstacles that even your smartest, most dedicated developers loathe encountering. According to a recent poll by Stepsize, more than half (51%) of engineers have left a company or considered quitting due to a large amount of technical debt.

The bad news is that every company has tech debt. It is an inevitable byproduct of imperfect shipping code. (Note: all code is flawed and the fix is usually worth a lot more than $2.56.)

The good news is that as software reliability practices mature, new conventions of service-level objectives (SLOs) and error budgets are giving organizations better signals for recognizing when it’s time to pay down that technical debt. These are modern optimization strategies you should be taking advantage of to provide better visibility, context and urgency to your tech debt.

In this article, we will explore two common types of technical debt: “drag” debt and “future-scale” debt. I’ll discuss applying modern reliability techniques to recognize when to pause on features and focus on paying off debts, hopefully before your team looks for new jobs.

Read more of Alex's article here.

Featured image via Openverse.