How to work with legacy code with a HUGE technical debt?

How do you eat an elephant? 1 bite at a time.

When engineers are faced with a massive, legacy codebase, there are 2 common extreme reactions:

1. Run away from it
2. Rewrite the entire thing (which is usually a bad idea)

I have found that the optimal approach is the less exciting and more incremental one: Get stuff working within it, but clean up small to medium sized tech debt here and there along the way

Over time, the incremental gains will add up, especially if the team has a culture of doing it. The codebase will continue to suck and maybe graduate to just being mediocre, but at least it isn't getting worse and you'll learn a lot from being a "code janitor".

Longer term, it's best to figure out how to split off from the legacy infrastructure and write new features/services in modern frameworks instead of extending the old crappy one.

Here's a good thread about this: "How to build culture of owning technical debt?"

Also, this scenario happens at FAANG all the time. It doesn't matter how smart your engineers are - If you're engineering at scale, you're going to accumulate tons of jank. FAANG is also known for moving fast (at least in their prime), and moving fast produces lots of hacky, messy code. TikTok in particular comes to mind here as a lot of their documentation is in Chinese, similar to your French algorithms.

Since you're a Senior Engineer, I'm going to suggest something a little different:

Start with the business needs first.

Here are a few questions you can ask:

• What is the impact of the technical debt on the business?
• How does it affect the ability to deliver new features?
• What direction does the business see for this product (in the current iteration)?

In my experience, there are a few scenarios you might find:

• The product is stable but hard to expand.
• The product takes a lot of effort to keep stable.
• The product is on fire.

The product is stable but hard to expand

This means that new features take a long time to build and deliver. Quantify the value of this to the business (dev hours, lost $$, etc). Look for the largest bottlenecks (most modified areas in the code) and propose a project to improve them. Tie the business value to this project. Talk to your manager/lead, prepare an estimate of work and volunteer to lead the project.

The product takes a lot of effort to keep stable

In this case, you're handling lots of customer issues. A big chunk of development effort goes towards fixing bugs (which means $$). This is unsustainable in the long term.

I'd recommend a two-pronged approach:

• Start by contributing toward making the product better. This means fixing bugs and being a team player. But, don't stay here for too long...
• Look for patterns when you work on bugs. Identify ways to fix things systemically.

Your goal as a senior engineer is to force-multiply and make things easier for others. So, focus your effort on where you can deliver the most impact.

The product is on fire

I've worked on a project like this before. The technical debt and bug backlog were impossible to overcome. Counterintuitively, in these cases, you want to stop spending all your time on fixing bugs. If you don't do this, you'll never dig your way out.

As a senior engineer, your goal is to communicate this technical reality to your manager and business team.

In our case, we ended up mass-closing all older tickets. For newer tickets, we categorized them by impact and started addressing the root cause. If this meant rewriting a particularly buggy module, that's what we did.

Doing this will help you stabilize the product quickly so that you can move on to the above approaches.

In all of these cases, your goal isn't to rewrite everything wholesale. But, you also don't want to just chug along one ticket at a time. Rather, focus your time on impact and business value.