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.
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:
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.
Thank you Alex for your answer. It is really helpful. I will check the thread.
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:
In my experience, there are a few scenarios you might find:
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.
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:
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.
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.