Over 10 years I've used five languages, 10+ web frameworks, and probably over 500 repositories. You might be justified in calling me a fad-jumping technology enjoyer. Like many, I've been biased towards what's new and shiny and trending on the first page of HN.
But that's not representative of the industry as a whole. Did you know there are indie game developers who carefully craft their own engines and, over periods of 15+ years, diligently support the same frameworks and codebase across multiple projects? Eskil Steenberg is who I'm talking about. He is a legend, and you should explore his world. He talks about being ALL IN on C89, a 36-year-old standard for the C language. The platforms he builds will compile to anything and outlast anything built for the web.
Legacy software is a dirty word, but my point of view is different. Imagine your ancestors using software written 100 years ago—that sounds like a fantastic legacy, something SO useful that it can still be used in the future. This is what attracted me to C89. It will compile on computers 50 years in the future because it compiles on computers from 25 years ago. The excitement of building software that just works and will continue to work is a strange concept for someone who has spent a decade following industry trends in web development.
We don't build software with a 50-year lifespan for really sensible commercial reasons. It's not worth spending 5x as long to develop a system when you're still exploring product-market fit. Once you extract the value, you rarely go back and rewrite. This commercial context is where I have focused my career. You learn a ton and explore a lot of different approaches to solving the same problems.
You are more employable when you have exposure to a wider set of technologies and approaches. The cards are stacked against you if you're ALL IN on a certain tool or approach. Hiring managers care a lot about curiosity in technology as a proxy for aptitude at the job. Writing in the latest version of a tool or language is a kind of signaling to the labor market that you're going to upskill and bring fresh ideas to a team.
When have you ever seen a rewrite choose the exact same stack? In my experience, it simply never happens. We choose the new shiny thing based on promises that it will last longer, be faster, or pay us more to write it. Rewriting can be in the same language and solve the old problems while achieving the needed outcomes in many cases.
But what about the other side, writing software that lasts FOREVER? There are niches in the industry that take this completely different approach. Solo devs like Eskil are an example, he grows a set of libraries, and takes them from project to project --extending them as needed. DHH is another. Yes, he does rewrite Basecamp—but it's always Rails, and it's always an incremental improvement. The same system lives on with minimal churn in technology.
Low level programming for hardware often means a longer time between patching -- your code might be in space, under the ocean or deep in a mine. The systems need to last in the most harsh environments known to man: radiation, extreme hot and cold. To succeed, they MUST match the environment with an equally hardcore approach to quality and longevity. From the hardware layer through to the software layer, this permeates everything.
The first ten years of my career have focused on increasing speed of shipping, because building the right thing was the biggest risk. You iterate faster to get more feedback and change your trajectory. In the hyperactive web engineering world, you often stop earlier with the realization that this code doesn't need to last longer than a couple years. What drew me in to exploring the world of old school C, was the philosophy of it's engineers -- write 5x the code, but also get 5x the longevity with the end system. There is undoubtedly things to learn from each other when you cross domains.