Ask HN: Why did back-end development explode in complexity?

I have never met a full-stack developer that is comfortable with the full stack. I am also pretty sure full-stack was coined by recruiters and marketing folks to create a technical middle class.

This is also encouraged by vendors. Old-school "boring" solutions (that you can't rent-seek over) are shunned in favour of proprietary reinventions of the wheel that do the same but poorly or more expensive. This in turn incentivises "engineers" to do resume-driven-development and implement those suboptimal products/services at their own company, and the cycle repeats.

I really don't think this is a productive question or will produce productive answers that aren't tribal and arbitrary.

Some folks will blame "the system" or "the man", others will claim it's not hard and you just need to RTFM, still others will explain how much harder it was "back in their day", and some folks will question the question (like me).

But nobody is going to drop some single piece of information or knowledge that'll "answer" the question; "In 2004 Linus Torvalds declared that all backend systems must contain three additional technologies than the currently mandated two." If only it were that simple.

Things are hard until they aren't, complex until they're simple, convoluted until they're straightforward as can be. The line is different for everyone, so nobody knows what your line is, which means nobody's going to answer the question in a way that will satisfy you, and if they do, it'll only be helpful to a few folks (your folks) and possibly actively harmful to others.

Maybe if you had a specific question that illuminated where you're coming from, folks could provide better answers...

I think some of this is because it's way harder to write a new library for a well-established language & ecosystem and become well-known for it, than it is to do the same in a new ecosystem. This goes for languages and frameworks both—React, for example, generated tons of opportunities like this, to become known for something by basically solving a problem that'd already been solved 1,000 times—but with React.

Like, if you want to build your résumé and get offered some of the cushier programming-adjacent gigs and get to present at prominent conferences and generally become A Name, how likely is that to happen if you try to launch some big web framework, or an auth library, or an ORM—in Ruby? Or Java? Nah, too crowded.

But if you pick some up-and-coming language (that's up and coming in part because everyone involved is doing exactly what you're trying to do) or hook your wagon to some new framework's (or database's, et c.) hype cycle, well, now you're talking. As a bonus, many of these projects require little or no novelty—it's all well-trod territory. Just half-competently do what hundreds of others have already done, succeed at promoting it (tellingly, this is the harder part) and you're a rockstar. And hell, maybe doing all that does demonstrate some kind of remarkable and valuable skill, for all I know!

But the point is, if that's the kind of thing you're trying to do, you need churn, and a bunch of people all trying to accomplish the above drives that very churn. Very little of that activity actually advances the industry, and the churn itself is a huge drag on everything.

Maybe it's a general comment to both back-end and front-end. To me it seems that down in the trenches coding is getting more complex, even though frameworks hide more and more complexity. Languages and frameworks gain features and they don't necessarily shed old ones. I've been working in C# for near 15 years. Each C# and .net release brings more to the table. Often these are features, which simplify things, at the same time the old ways still work. Googling often returns N solutions, each from a different era. I imagine it can be confusing for newcomers to even start. As for the growing complexity in the world of backend, I think, when needed, the best tool against it, is pragmatism.