Low level is easy (2008)

A good way to learn game engines is to build a series of games that only require you to learn a few new things with each iteration. The same way you wouldn’t roll your own game engine that has all the features of Godot on your first try.

The difficulties of backends usually come from one of these areas that I don't think you're giving proper credit:

- scale - a frontend shows one user's view at once, a backend may need to be updating state for millions of users without slowing anyone's experience down. But these sorts of things are somewhat different than just "backend code", it's often closely tied to infra and data designs, which doesn't necessarily look like "backend coding" but is critical to make the rest work.

- business logic complexity - often the backend teams are tasked with working with frontend to figure out a simple, user-friendly API surface for the app and also to figure out how to make that work with the various not-written-down, not-even-fully-enumerated business logic permutations and backend-data permutations that could be going on. If they do their job right, the frontend can show different screens with values from the API ready to plug in for a particular scenario without having to worry about the combinatorial rules behind the scenes that led us to want to show the user THIS screen instead of any other one. The difficulty there isn't a mathematical or "hard" one, it's that the product team probably has no idea just how gnarly the set of business rules they sketched out actually gets. A backend has to support everything the frontend client can do today, but often ALSO support a bunch of things the public frontend apps don't yet do (whether this is for admin tasks, or for future readiness, or what).

I'm not sure I see the significance of the number of symbols in UIKit - you usually don't need all of them, I assume, and I know that there are some common patterns that get re-used a lot. Is it so different from in backend when there are dozens of databases you could choose, and a bunch of frameworks for each of a bunch of different languages you could choose, but for most problems it's not going to make a huge difference?

One thing that often hides the difficulty on backend is that the frontend team might be interacting with just one or two backend teams that then interact with a different set of teams behind them, etc. But the true "backend vs frontend" question has to include ALL of those teams, even the ones you don't directly interact with, since they're all in the critical path.

"Hard frontend problems are harder than easy backend problems" - ok, sure. But that's not a very interesting comparison.

Someone else has already mentioned in this thread that backends only ever interact with other programs, not humans. This fact alone makes it easier to design, implement and scale. And like I said elsewhere it is in fact so much easier that a backend can be built to be 100% correct and bug free, while for any more or less interesting and useful frontend it is practically impossible to achieve.

Anyone who becomes sufficiently experienced in a domain will inevitably learn and take advantage of their underlying platform's characteristics.

A web developer who wants an app to load and render quickly will take advantage of the browser's characteristics. For example, loading compressed assets in the right order to get a short time-to-first-paint, updating styles without reflowing the page, using requestAnimationFrame to render animations at a consistent frame rate and play nicely with the event loop, etc.

Likewise, a systems programmer ends up learning the quirks of their OS and hardware. For example, loop tiling to take advantage of cache locality, reducing data dependencies to reduce pipeline hazards, using splice() to copy data on Linux to avoid context switching, etc.

It's all just programming. Even if the distance from hardware is different, the concepts are consistent. Historically, hardware has been under-documented, which I think led to the community glorifying low-level programming. But under-documented and buggy platforms are essentially universal nowadays, so I think the low-level vs high-level distinction is not very useful.

That's nonsensical. User input is passed to backends all the time, and results in just as many difficulties there. From SQL injection and other "untrusted input" problems, to dealing with migrating five years worth of user data to a new system because the old backend can't keep up, to trying to keep every piece of data in a consistent state.

Look at CAP theorem: it literally says "you can't have a perfect system here, you have to choose." That's a backend problem with literally no "100% correct and bug free" answer!

(With regard to the original article here, your error is that you're assuming modern backend software is closer to "low level" than "high level" compared to frontend code. It really isn't. And in terms of running your code, it's often at a HIGHER level than an app running directly on a user's device - you're in containers on VMs on someone else's hardware in a cloud environment, say.)