I've spent most of my adult life as as "full stack" developer, out of necessity: I build the whole banana on my own and typically work on projects on my own (about 3/4 of the last 20 years). I'm better at some aspects than others and I enjoy some aspects more than others, of course (and I offload/automate anywhere I can).
From the late 1990s until five or six years ago, it was fairly easy to keep up with the latest interesting stuff in terms of full stack. Adjustments were modest year to year. At this point I've entirely given up trying to keep up with the very rapid fad switching that has been going on. Real full stack is now only possible if you freeze pretty strictly across the stack and don't try to keep up as the next fad rolls in for a given part of the stack. If you try to keep up with all the fads now, it'll burn you out (and most likely make you hate what you do as you realize how pointless the constant switching is).
I've found - as you'd expect - that abandoning the stack rat race hasn't had any negative impact. Most of the latest fads are entirely unnecessary and bring nothing to the table that prior numerous solutions didn't already deliver toward building, launching and maintaining product.
This is the other side of the coin. A lot of folks in the industry, especially on the younger side, tend to believe they are operating at FAANG levels of data and complexities. What happens is that you get convoluted, over-engineered architectures and applications which really do nothing other than pad resumes. The next time you are listening to a talk or reading a blog entry that drones on about how complex their stack is, stop and think for a moment: "Do they really have traffic/MAU levels that merit this approach? Are they really operating on data that is PB scale or just a few GBs?" More often than not, the answer is an emphatic No ... or "Can this application be distilled down to a vanilla MVC app with a few cronjobs running?" Yes.
>What happens is that you get convoluted, over-engineered architectures and applications which really do nothing other than pad resumes.
But padding resumes is one of those seemingly fundamental problems of any industry (or bureaucracy). Many poor decisions by (middle) management come down to padding resumes - when the consequences of bad decisions eventually happen said managers are gone. Hell, you could even argue that a lot of higher education is about padding your resume rather than learning skills. Unfortunately, it seems that we have to live with the added baggage of "padding resumes".
Maybe the point _is_ to pad resumes, ie Resume Driven Development. The incentives align for this to take place, as companies want to hire for the trendiest and newest technologies, simply as a way of virtue signaling that they're good, regardless of the efficacy of the new technologies. If I can job hop every few years while padding my resume, and get paid 30% more each time, for some N job hops, why wouldn't I? In this case, when you follow the incentives, you see why this happens. That the incentives of the business don't align exactly (stability, speed, efficiency to some regard) is inconsequential to the developer who wants to increase their value.
I will argue that some projects are definitely overly architectured simply for the sake of gaining experience in doing so. If everyone waited until they actually had Google scale problems to learn how to create scalable architecture, then only a small subset of people would have that skill. It is the initiative of doing so and ability to point at previous history of successfully completing such projects that give these people the opportunity to work on problems that actually require said complex solutions.
From the late 1990s until five or six years ago, it was fairly easy to keep up with the latest interesting stuff in terms of full stack. Adjustments were modest year to year. At this point I've entirely given up trying to keep up with the very rapid fad switching that has been going on. Real full stack is now only possible if you freeze pretty strictly across the stack and don't try to keep up as the next fad rolls in for a given part of the stack. If you try to keep up with all the fads now, it'll burn you out (and most likely make you hate what you do as you realize how pointless the constant switching is).
I've found - as you'd expect - that abandoning the stack rat race hasn't had any negative impact. Most of the latest fads are entirely unnecessary and bring nothing to the table that prior numerous solutions didn't already deliver toward building, launching and maintaining product.