Is it up to the newer developer to pay back others' technical debt?

Struggling with Legacy Code and not enough time to clean it up?
⛑️️ My First Aid Kit can help you rescue any codebase quickly and safely!

You recently joined a new team. Maybe a new company.

As you get used to your new colleagues, you also discover the codebase they’re working on. Very soon, you embark on features and bug fixes, as your team needs to deliver. So you dig into the existing code you don’t know yet…

But after a few weeks digging into the Legacy Code to implement a feature, you might feel despair.

“It’s taken me a month so far and I’m still not done…”

“The one who wrote the code I’m refactoring could get it all done in a day!”

I get it. Maybe the developers who wrote the code are still in the company. Maybe they’re now working on new, exciting projects!

And there you are, thinking that editing someone else’s code doesn’t feel as cool as writing something new. Wondering if it’s the best use of your skills when more experienced developers could refactor the code in no time. 😩

Maybe you’re a junior developer or an intern and you think it’s natural to get the bitch work nobody else wants.

Or maybe you’re an experienced developer who knows that it’s part of the job, you don’t always work on the interesting stuff.

OK, stop a minute and think about it

First of all, that feeling of struggle is normal. Even after a few weeks.

It’s the nature of Legacy Code.

Legacy Code is the code you need to change and you struggle to understand.

That means it will get easier. As your experience with the codebase grows, you’ll have more context and knowledge to refactor the code.

In fact, coding is not the problem. You recently joined a team. You need to get used to the system, tools, and code they have.

After 1 year you’ll feel comfortable enough. Just be patient.

How can you make the best use of your time?

There’s actually something you can do better than anyone else.

Because you’re in a very unique position.

Document It.

You’re learning the system, tools, and code. You are giving it a fresh pair of eyes. You’re bringing your point of view. You have the best point of view on what’s clear and what’s not!

Regardless of your seniority, you’re the best person to point out the things that are not clear! And clarify them.

Initiatives you can take already 🤠

  • Some concepts you don’t understand? Ask your colleagues and write that knowledge somewhere. Anything would do.
  • Build a glossary of the jargon used within the team.
  • A piece of code is hard to understand? Add comments as you discover what it’s doing.
  • You don’t understand what this variable represents? Rename it when you figure it out!

Do that. Make the code a better place. A tiny bit at a time.

Little by little, file after file, you’ll make the code better.

Not good, but better.

Progressively, you’ll make the whole team uncover the unknowns, explicit the implicit. You’ll gain trust as your expertise grows.

Others will really appreciate you for it.

And you’ll finally enjoy working on others’ technical debt!

Nicolas Carlo

Written by Nicolas Carlo who lives and works in Montreal, Canada 🍁
He founded the Software Crafters Montreal community which cares about building maintainable softwares.

Similar articles that will help you…

It's like coding in the dark!

A look into Catherine Hicks' white paper "It’s Like Coding in the Dark: The need for learning cultures within coding teams" (Catharsis Consulting).

7 advice to help you inherit a legacy codebase

My recap of the most common and useful advice one can give to tackle Legacy codebases.

Design Patterns, Empathy, and Reading Complex Code

4 great talks on Legacy Code that I had the pleasure to host. A focus on empathy and getting into complex codebases.

Technical Debt, Rewrites, and Refactoring

5 great talks on Legacy Code that I had the pleasure to host. Learn how to prioritize Tech Debt and rewrite systems incrementally.

← Find more tips to work with Legacy Code