> Nah, not really. My second example has to do with internal frameworks inside a FAANG, where the average half-life of code is about a year (i.e. half your code is deprecated or deleted a year after you write it).

That's exactly the same web-dev mindset, only applied to backend code. I find it remarkable that you take a half-life of 12 months to be a given, rather than a screaming red flag.

Yes, the world changes, and code needs to change along with it, but it doesn't change that much. Replacing 50% of your codebase every 12 months, year after year, indicates to me that the organization is just replacing poorly architected code with different poorly architected code, not better code. The codebase is on a random walk, and any forward progress it makes is due to chance and evolutionary pressure, rather than reason and design.

Remember that the architecture competency in FAANG exists in the context of a 2-3 year average tenure. And this elides a tendency to change teams internally even more frequently than that. It is unlikely that a senior engineer rated "Exceeds" at design and architecture in Silicon Valley has ever learned from or been evaluated on the consequences of their own decisions at more than 4 years out. Median probably one year.

An average tenure hides a good number of people with longer tenure than that. I'm personally a counterexample to your point, for instance, and I know quite a number of others on other teams at my company (one of the FAANGs).

Turnover is definitely not uniform and a 12 month architecture lifespan is not, in my experience, either normal or healthy.

My experience is that architectures usually last 2-3 employee tenures, the point is the original architect usually doesn't see the outcome of their work.

I don't think workers' entire skillsets are obsoleted by any of those changes, unless you specialized in trend-chasing (obvious risk) and maybe if you refused to board the NoSQL train. But even now those 2003 RDBMS skills have a place again! High scalability companies are back to using traditional DBs where it makes sense.

I agree with this. While the flavor of the year frontend stack might change, since 2008 when I started dabbling in frontend, the fundamentals really haven't changed: understanding DOM, understanding the JavaScript execution model, understanding the layout models, understanding the complexities of dealing with data binding over asynchronous events and simultaneous users, and so on. jQuery didn't change any of that (although it drastically improved ergonomics). Angular didn't. React didn't either.

My experience has been that paradigms and tools can move fast and are relatively straightforward to pick up. Deep understanding of the underlying problem domain and the systems underneath the abstractions is harder to pick up, but the concepts move more slowly.