I'm working on myself to perform like a senior software engineer at a FAANG company, and by doing your courses and following you on youtube, I understand that being a good at debugging is one of the greatest qualities. But I am facing couple of problems. I work in a project where the technical debt is huge, the documentation is complicated (sometimes in code, sometimes on google drive, sometimes in the form of an algorithm written in French by a non-technical person). Only people who have been working with code for 3 years or more seem independent (And they only have time for themselves), thus, many of us sometimes feel lost. A lot of money has already been invested and it is in production. So no time to rewrite the services, where more than 100 people contributed. Do you have any advice or steps to deal with this type of problem? I know that among the FAANG there is a 0% chance of having this case, but still, any advice will mean a lot to me.

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: Run away from it 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.

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

Senior Software Engineer at Taro Community4 months ago

I'm working on myself to perform like a senior software engineer at a FAANG company, and by doing your courses and following you on youtube, I understand that being a good at debugging is one of the greatest qualities.

But I am facing couple of problems.

I work in a project where the technical debt is huge, the documentation is complicated (sometimes in code, sometimes on google drive, sometimes in the form of an algorithm written in French by a non-technical person).
Only people who have been working with code for 3 years or more seem independent (And they only have time for themselves), thus, many of us sometimes feel lost.
A lot of money has already been invested and it is in production. So no time to rewrite the services, where more than 100 people contributed.

Do you have any advice or steps to deal with this type of problem? I know that among the FAANG there is a 0% chance of having this case, but still, any advice will mean a lot to me.

318318 Views

44 Comments

Other Great Discussions

What is the effective way to understand new repository in order to make the required changes in that repo?

What's the difference between a low performer software engineer and a high performer?

What’s the most effective way to switch domains in tech?

How can I write great code faster?

What's the core insight behind quick growth?

Discussion

(4 comments)

19
Alex Chiou
•Tech Lead @ Robinhood, Meta, Course Hero
4 months ago
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:

Run away from it

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.
- 1
  Senior Software Engineer [OP]
  •Taro Community
  4 months ago
  Thank you Alex for your answer. It is really helpful. I will check the thread.
3
Roman Yusufov
•Senior Engineer @ Amazon, Founder @ Roman Yusufov Coaching
3 months ago
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.
- 0
  Senior Software Engineer [OP]
  •Taro Community
  2 months ago
  Hi Roman,
  
  Based on your response, we are currently dealing with the last two cases, and we will encounter the first case if we address the two initial cases poorly. Maintaining product stability requires significant effort, especially as our teams continue to grow each month. The product is thriving, but the context is somewhat unusual due to how it have been implemented initialy and how team get formed.
  
  To summarize, my main goal is to help the business escape this challenging situation and make a meaningful impact. Given my context and your insights (from Alex and yourself), I am committed to facing this challenge head-on.
  
  I plan to reevaluate how I communicate with my clients and managers, especially since they may not have a technical background. I aim to be a team player by collaborating with colleagues across business, support, and engineering to generate good ideas and implement them while simultaneously addressing bugs (which I have already begun).
  
  I will tackle the challenges one step at a time. For "urgent tickets" in the backlog, I will focus on delivering quick solutions first, then identify patterns to clean up the code as needed. I will categorize tickets to find root causes and will refactor or redesign as necessary.
  
  To anticipate the first case (where the product is stable but difficult to expand), I will identify bottlenecks and propose a project plan, including time estimations, and align it with our business objectives.
  
  Thank you,
  Mouhamed