I kinda specialize at getting into legacy code bases, understand how they work, and quickly be able to make changes and clean things up.
But I don't think I've read any books on that. What I do is read the code!
I think can do this mostly because I'm interested in it. SW projects die because the code isn't maintained properly and becomes unworkable. So I work on being the counterforce to that, keeping the project alive.
Most engineers are into writing new shiny code, and hate "cleaning up other's mistakes". That's also often rewarded. The results are well known :)
Yep, that is definitely a skill. And you are doing exactly what I recommend: slow down and take the time to read the thing and understand it. Then go forward from there. Your interest also shows that you are intrinsically motivated, which many people are not.
You’re right that there are very few books available showing people how to do this. Usually “Working Effectively with Legacy Code” is recommended but it’s just one book and so can’t cover everything. It’s an area where on the job training and experience definitely makes a difference.
Reminds me of the story of the high school graduate who noticed that all of his peers were “following their passion” by pursuing various undergraduate degrees in underwater basket weaving, etc…
Rather than follow suit, he went in the opposite direction and did what no one else wanted to do… he started a septic tank cleaning company. He said that it was hard work, but lucrative… and that after a while, he woke up one morning and realized that he was passionate about other people’s shit.
I knew a guy in real life who's dad built a profitable septic tank company from scratch. he expected his son to follow in his footsteps and take it over one day. The son passed; he could just not see himself in that industry and went into marketing. Caused a bit of stress in their relationship.
I can imagine how that conversation went. Something along the lines of “I’m sorry, dad. I respect what you’ve built, but I just don’t want to deal with this shit.”
But I don't think I've read any books on that. What I do is read the code!
I think can do this mostly because I'm interested in it. SW projects die because the code isn't maintained properly and becomes unworkable. So I work on being the counterforce to that, keeping the project alive.
Most engineers are into writing new shiny code, and hate "cleaning up other's mistakes". That's also often rewarded. The results are well known :)