Stop rewriting software for the sake of rewriting
Knowing when to avoid fighting unnecessary battles is one of the most valuable skills to have
When I was barely a couple years into my junior developer stage of my career, I remember being so opinionated about what tech stack to use and what shiny tools should be ideal for any given task. I had a hammer and everything looked like a nail, basically.
This was around the early 2010s – around that time I was really passionate about C# and how sophisticated the .NET Framework was in terms of not reinventing the wheel and just reusing the built-in tools it provided. I was familiar with that tech stack based on a couple of personal projects I was tinkering with at the time, but on the other hand, I was faced with the need to develop and support large production systems developed many years prior using a mix of old-school ASP and VBScript.
Actually, I asked about it back in 2011 in Stack Exchange and found it. And of course it was closed for being off-topic. Classic SE.
There's something about the young developer mindset that thinks that knows better and wants to rewrite and rebuild everything from scratch using the shiniest tool available. I look at my old SE question and cringe about how naive and frankly stupid I was. Nothing wrong with trying to improve things, of course, but many years under my belt I definitely I'm more inclined to left things untouched if they are working as expected, no matter how old the tech
New isn't necessarily better
I see this mistake being perpetuated by newer generations of developers. I find younger developers dismissing well tested bodies of code simply because instead of putting in the hours to understand the underlying concepts behind it, they have used a new library that does the same. Old doesn't equal bad but apparently we need to spend a good amount of time making tons of mistakes to realize that.
I've seen (and done) rewrite efforts that fell flat because the motivation was to swap old and boring tech A with new and cool tech B. A well-rounded rewrite should be based on addressing tech debt and understanding why old-tech A is falling short and how new-tech B addresses these shortcomings. A good plan of attack also doesn't hurt when embarking on such endeavor.
Well seasoned developers will usually have a good amount of battles under their belts. We know a thing or two, and knowing when to avoid fighting unnecessary battles is one of the most valuable skills to have.
Rewriting for the sake of rewriting is never a good idea but seems to be a necessary rite of passage for relatively new developers.