Berlin

November 4 & 5, 2024

New York

September 4 & 5, 2024

London

June 16 & 17, 2025

Refactoring: Managing technical debt before it blows up in your face

Amanda Sopkin invites you to come and learn how to develop your own framework for addressing technical debt as a company.

Speakers: Amanda Sopkin

Register or log in to access this video

Create an account to access our free engineering leadership content, free online events and to receive our weekly email newsletter. We will also keep you up to date with LeadDev events.

Register with google

We have linked your account and just need a few more details to complete your registration:

Terms and conditions

 

 

Enter your email address to reset your password.

 

A link has been emailed to you - check your inbox.



Don't have an account? Click here to register
January 21, 2022

Most engineering teams maintain their own balance between feature work and technical debt. This varies according to culture, funding phase, and even the product area. With little provocation, most engineers could probably rifle off a laundry list of items they’d like to tackle to improve their workflow, speed up processes, or just maintain their own sanity. However, work on technical debt for too long and you’ll lose sight of customer focus, neglect important features, and your engineers may begin to miss the shiny feature work that elevates their careers.

So how do we decide when dealing with tech debt is worth it? On the ground, many developers struggle to find the balance between striving to improve existing code and letting good enough alone by accepting certain shortcomings. As a new developer to a team it can be difficult to understand existing strategies and patterns that are sometimes flat out bad (and often openly acknowledged as such). Often the result of tight deadlines or unclear specifications, even the best developers write code they later look back upon and shudder.

Come learn how to develop your own framework for addressing technical debt as a company. I will discuss strategies for prioritizing technical debt, ways to “stop the bleeding” of bad practices, and potential complicating factors.