You'll need to duplicate existing code and make it your own or risk adding one piece of new functionality and breaking things that were using that code in 20 unexpected places.
Build new isolated code with best practices.
You'll slowly become familiar with it and get a feel for the best way to make updates and changes safely.
To answer your question as formulated in the title: is it worth it?
For further feedback, could you write differently than someone trying to justify their job to a non-technical person who can fire them by stretching boundary induced theorized neuro-transmitted user experience triggering value-releasing velocity multipliers? You're safe here; I didn't understand what you wrote.
Somewhat clarifying question: do they care about it? or not so much? i.e. if you are the only one, and you don't have the needed freedom/ time/ resources/ help-from-everyone-else..
Anyway, legacy code should be tread very lightly, esp. one with missing why's. Your job becomes finding those why's .. and most of those may have nothing software-ish in them.
One simple single-aspect change at a time. Try it.. checking it does not go regression (might be impossible - well, then Hoping it won't). Undo or go-forward. Repeat.
Write down/Document everything you find. Or assume. Or think of. (do it for your future self)
and yes, have Fun.. the always missed part of the trio functionality-quality-time
Thanks for these suggestions. That is really good advice, writing down gained knowledge and assumptions, then presenting it to them for clarification or my future self. The codebase is quite massive, and while they have tests, the coverage is just a fraction. So, I might need to build more. To answer your question, I think the industry expectations have changed with AI and the BS of big-tech CEOs. But that is just me guessing based on the pressure I'm receiving.
Try to make map/s. Something visual. Of one or multiple aspects. Cross-reference func/class is easiest but too low level ; needed is crossreference of notions - in space AND time.
Did such thing several times, helps a lot. in my last gig i landed as "owner" of 300K js , in-house event-sourcing-from-scratch.. a complicated mess although somehow organised because of the events. There was a team working on those, but in somewhat darkness - noone knew why x-y-z is so. After some staring at code for a while, found few patterns - some repeated, some once-off, and build a mapper (i am python guy, used Esprima as js parser) to extract and build the graph of domain-event-reason-consequence for all available cases, then made visual maps of those 4 aspects (graphviz). And although noone from the team learned to look/use those, i used them, to guess eventual consequences of some change or answer why this-and-that happened, and shown to various interested parties as "very elevated documentation" :)
rule 2 underpromise so you can overdeliver. if you dont meet your short deadline they'll think you're lazy or incompetent. if finish in your long deadline they'll think you are employee of the month. always x2 or x3 your estimates.
rule 3 hang out with the seniors, listen to them. they know the landmines and how things are. not only in technical but also in office politics.
rule 4 spend time with people closest to your end users. this may be your sales people and support people. they dont code, they dont know the inner technicals, but they know the things that matter business wise.
Thanks, yes, refactoring. Please allow me to vent.
First, I totally agree with you on Rule No. 1. I would never refactor legacy code or suggest a rewrite. It's always a terrible idea. The downside is that I worry I might look like a ghost engineer. This is why I hate this industry sometimes. I heard about this paper at Stanford on ghost engineers a few weeks ago. Where LOC as their basis, it's just absurd. It went to the mainstream media as well, but looking at the paper, it has no metrics on the non-coding aspect of programming.
It seems the industry hates the dev, like we should not be paid this high. Did execs make poor product choices? Let's fix this by increasing shareholder value by another round of layoffs. Which department? Engineering, we have metrics who does not provide enough value!
Needing to explain the complexity of the task to your boss, might suggest the reasons none of the previous committers are still working at the company.
Of course it might be coincidence that you are already feeling burnt out; the company has not retained developers before you; and does not have relationships with those developers where they are available as consultants.
If you decide it probably isn’t coincidence, it might make sense to have workplace expectations consistent with such a company culture.
Sometimes a lousy job is better than looking for a job. Sometimes it’s not. Good luck.
Forget about best practices and refactoring.
You'll need to duplicate existing code and make it your own or risk adding one piece of new functionality and breaking things that were using that code in 20 unexpected places.
Build new isolated code with best practices.
You'll slowly become familiar with it and get a feel for the best way to make updates and changes safely.
Hi.
To answer your question as formulated in the title: is it worth it?
For further feedback, could you write differently than someone trying to justify their job to a non-technical person who can fire them by stretching boundary induced theorized neuro-transmitted user experience triggering value-releasing velocity multipliers? You're safe here; I didn't understand what you wrote.
Somewhat clarifying question: do they care about it? or not so much? i.e. if you are the only one, and you don't have the needed freedom/ time/ resources/ help-from-everyone-else..
Anyway, legacy code should be tread very lightly, esp. one with missing why's. Your job becomes finding those why's .. and most of those may have nothing software-ish in them.
One simple single-aspect change at a time. Try it.. checking it does not go regression (might be impossible - well, then Hoping it won't). Undo or go-forward. Repeat.
Write down/Document everything you find. Or assume. Or think of. (do it for your future self)
and yes, have Fun.. the always missed part of the trio functionality-quality-time
Thanks for these suggestions. That is really good advice, writing down gained knowledge and assumptions, then presenting it to them for clarification or my future self. The codebase is quite massive, and while they have tests, the coverage is just a fraction. So, I might need to build more. To answer your question, I think the industry expectations have changed with AI and the BS of big-tech CEOs. But that is just me guessing based on the pressure I'm receiving.
Try to make map/s. Something visual. Of one or multiple aspects. Cross-reference func/class is easiest but too low level ; needed is crossreference of notions - in space AND time.
Did such thing several times, helps a lot. in my last gig i landed as "owner" of 300K js , in-house event-sourcing-from-scratch.. a complicated mess although somehow organised because of the events. There was a team working on those, but in somewhat darkness - noone knew why x-y-z is so. After some staring at code for a while, found few patterns - some repeated, some once-off, and build a mapper (i am python guy, used Esprima as js parser) to extract and build the graph of domain-event-reason-consequence for all available cases, then made visual maps of those 4 aspects (graphviz). And although noone from the team learned to look/use those, i used them, to guess eventual consequences of some change or answer why this-and-that happened, and shown to various interested parties as "very elevated documentation" :)
rule 1 dont try to be clever by refactoring
rule 2 underpromise so you can overdeliver. if you dont meet your short deadline they'll think you're lazy or incompetent. if finish in your long deadline they'll think you are employee of the month. always x2 or x3 your estimates.
rule 3 hang out with the seniors, listen to them. they know the landmines and how things are. not only in technical but also in office politics.
rule 4 spend time with people closest to your end users. this may be your sales people and support people. they dont code, they dont know the inner technicals, but they know the things that matter business wise.
Thanks, yes, refactoring. Please allow me to vent.
First, I totally agree with you on Rule No. 1. I would never refactor legacy code or suggest a rewrite. It's always a terrible idea. The downside is that I worry I might look like a ghost engineer. This is why I hate this industry sometimes. I heard about this paper at Stanford on ghost engineers a few weeks ago. Where LOC as their basis, it's just absurd. It went to the mainstream media as well, but looking at the paper, it has no metrics on the non-coding aspect of programming.
It seems the industry hates the dev, like we should not be paid this high. Did execs make poor product choices? Let's fix this by increasing shareholder value by another round of layoffs. Which department? Engineering, we have metrics who does not provide enough value!
How do you explain this to your new boss?
Needing to explain the complexity of the task to your boss, might suggest the reasons none of the previous committers are still working at the company.
Of course it might be coincidence that you are already feeling burnt out; the company has not retained developers before you; and does not have relationships with those developers where they are available as consultants.
If you decide it probably isn’t coincidence, it might make sense to have workplace expectations consistent with such a company culture.
Sometimes a lousy job is better than looking for a job. Sometimes it’s not. Good luck.