Ask HN: How do you maintain a legacy codebase solo?
Hey friends, I hope you are all doing well. So, I've been studying the recent layoffs.fyi annual data, It seems the great reshuffle has slowed down.
It has been months since I got hired by a small company. I suspect everyone here got laid off before I was hired because by looking at the names of the commit logs, I can see that these people are all absent from the company.
I'm already burned out with this new position as a solo dev ai/ml full-stack software engineer.
Let me share my thoughts for a moment:
I'm mostly on non-coding activities when maintaining existing code
It's hard to provide estimates. Work is done by theorizing logically meaningful sequences for a real-world business requirement, usually in unpredictable, non-linear pain to comfort velocity.
Abstractions and functions have deeper design theories, and therefore, the user story must be understood when it is theorized and written. We have to assess the previous dev's choices and why the current was picked.
Tacit knowledge - on which we create a mental list of value-assessed design choices and their theoretical contribution to the next item in the sequence. Eventually, leading their overall contribution to the real-world business model.
i.e. if the business required this line of code to be made, therefore there is a value-metric involved, and this must be carefully assessed before altering the code.
Given a threshold of comfort, only then can we possibly alter the code. Deducing and isolating the root cause and, lastly, reproducing the error.
How do you handle legacy code? How do you explain this to your new boss? This full no-scope full-stack 360 is very overwhelming; I'm already burned out while job hunting. I provide them estimates and miss by a wide margin. I don't wanna go back to the job market.
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
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.