when I am supposed to fix tech debt? if every week there is another functionality going out that needs to be done yesterday? Do you think that I have to do it in my free time? Why should I even bother existing
Try to lie about how long will it take. Just today I finished* 1-month almost total rewrite of firmware for one of devices at my work. It started as a 1-week small rewrite of part of communication module for a small bug and was scheduled as that. But I've got chill PM and coworkers who will appreciate that now we can actually fix some 8yr old bugs in legacy parts of that code.
* well, now some testing of edge cases and another round of fixes but at least remote code updating works so we can ship those devices...
Edit: "Lie" is call to action here, there were some misunderstanding in comments. Previous start of my comment was "Lie. ..."
Let me tell you the tale of a man named Sisyphus...
I have never in my professional career seen a solo developer rewrite something from scratch successfully in isolation. It almost always turns into the developer leaving, either because they became burnt out being the sole SME, or it fluffed their resume enough for them to find a new job. Everyone else on the team is left holding the bag.
I'm actually more surprised your manager/PM let you do this. Most of the time this happens as a skunkworks thing.
Rewrites should always be incremental, never big bang, and never in isolation.
First phase was about 4 years. Second phase started, and I was there in year 2 of that. 6 month contract on my part. Took me months just to figure everything out.
Background - the core engine was PHP. The 'rewrite' was also PHP.
I left, and got some updates from a few folks later. They hired some python and JS people ("we can't find/hire any PHP people!"). And... they gave the python and JS people greenfield "rebuild chunks of this system". And months later, this was all spun as "PHP sucks, node rocks". Because.. well... look what was getting done. They couldn't hire many PHP folks because... they weren't paying terribly well compared to the level of skill required to deal with the core engine.
This was far less about tech as it was management. Giving a team of JS people who are all colocated, have a working system to inspect and emulate, can choose their own tools, and are given a long time frame... it's not all that surprising they had some success compared to "let one guy go off on his own and don't talk to him for weeks at a time".
Looking back, the second guy was trying to recreate much of the flexibility of the first system, but in a 'modern' way, which was very much not a great idea (the complexity and flexibility were the core problems, from what I could tell). The node and python teams avoided implementing much of the flexibility, and they could get away with it a bit more because by that time the business was more established, and had a better understanding of what they needed and what was not.
Part of how I viewed it was "it took 12 people 8 months to recreate 20% of what one person did in PHP in a couple of years". But that's certainly putting an overly pro-PHP spin on it. ;). By all means, though, having just one person be the sole person who knows 90% of the system, with no time given to train others... huge red flag. Took me a few months to suss out just how precarious that was, and I understand the business need to spread out the risk. Was just very annoyed that the "rebuild" decision was spun as "php sucks" instead of "solo-expert-working-in-isolation" sucks.