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.
