> Why is ... backend engineering the only software discipline that gets maligned like this?
Where do I even begin? The intrinsic difficulty of most backend problems is very low - read some customer data, save it to a database, call an external API, send data back to customer. The only effort you should have to put in is fighting boredom.
The web dev industry managed to overcomplicate this task to the point where even small startups targeting niche markets have architectures inviting race conditions over distributed systems with tens/hundreds/thousands of working parts.
It doesn't have to be like this. The problem is that your average web dev doesn't know how to scale down (optimize for space/memory/disk consumption), so instead they scale up (more computers). Scaling up isn't necessarily a problem if you know what you're doing, but I've seen a bunch of super-principal engineers regurgitating the popular scaling up buzzwords without actually understanding the tradeoffs. They choose a technology because Google is using it.
It's not fun to fix deep systemic problems in distributed systems when the system has already been running for a long time, and there's a large number of devs working on it. You can't just say "ok, everyone stop working, for a while, we'll take a couple of months to rewrite everything, the customer can wait".
What's worse it that this type of issues would've been obvious from the very beginning to anyone mildly curious to imagine what the future of such a system would look like.
Another type of common issue is slow queries, and the common "solution" results in eventual consistency.
I'll stop now.
> I never hear anyone talk about mobile development in the same way
Mobile development is just as bad, maybe worse. One overly complicated framework (Android), and another one that's fenced-off to non-Mac developers.
Where do I even begin? The intrinsic difficulty of most backend problems is very low - read some customer data, save it to a database, call an external API, send data back to customer. The only effort you should have to put in is fighting boredom.
The web dev industry managed to overcomplicate this task to the point where even small startups targeting niche markets have architectures inviting race conditions over distributed systems with tens/hundreds/thousands of working parts.
It doesn't have to be like this. The problem is that your average web dev doesn't know how to scale down (optimize for space/memory/disk consumption), so instead they scale up (more computers). Scaling up isn't necessarily a problem if you know what you're doing, but I've seen a bunch of super-principal engineers regurgitating the popular scaling up buzzwords without actually understanding the tradeoffs. They choose a technology because Google is using it.
It's not fun to fix deep systemic problems in distributed systems when the system has already been running for a long time, and there's a large number of devs working on it. You can't just say "ok, everyone stop working, for a while, we'll take a couple of months to rewrite everything, the customer can wait".
What's worse it that this type of issues would've been obvious from the very beginning to anyone mildly curious to imagine what the future of such a system would look like.
Another type of common issue is slow queries, and the common "solution" results in eventual consistency.
I'll stop now.
> I never hear anyone talk about mobile development in the same way
Mobile development is just as bad, maybe worse. One overly complicated framework (Android), and another one that's fenced-off to non-Mac developers.