I think there are two approaches to software development, and a gradient of people transitioning between them:
(1) I’m responsible for this system and I either have to understand this well enough to feel comfortable being directly responsible for it or delegate responsibility through my org structure or vendor contracts.
(2) I don’t understand how any of this works, it’s just a bunch of magical incantations that get me results, and one incantation is interchangeable with another.
Your dumbdumb fake engineer isn’t a fair characterization of (2) but I do believe a lot of tools in a lot of ecosystems are optimized for engineers without the depth of knowledge necessary to operate them under the API contract.
That’s totally fine when that API contract is provided by a responsible party you can delegate responsibility to. The problem comes in when you provide these “simple” API contracts on top of extremely complex internals and hand them to a developer/user who is ultimately responsible for the entire stack, internals and all.
In some cases (2) can offset risk using a “cattle” approach where multiple live versions of the system are kept up, changes happen one at a time, and you can fail over if something goes wrong and throw away the old state. I’ve met engineers who operate K8S clusters this way. They are clearly out of their depth with kubernetes, but they can fail over to a secondary and rebootstrap a bad cluster from scratch to get back to a good state. By keeping things disposable you exclude most (all?) failure modes other than “poison pill” bugs that repeatedly put your system into a bad state.
But, for the most part, these complex open source systems that try to hide complex internals give the illusion of delegating responsibility. You might get pretty far before an incident comes knocking and it’s time to pay the toll.
That's why I look down upon engineers with your mindset. I won't generalize all backend engineers as you did to frontend though.
I've met many who get it but of course prefer the peacefulness of controlling the execution environment and the limited state of a server.
Btw imo backend is boring because the reasons above, frontend has a lot more going on. As a full stack engineer I'd say frontend is much much harder, and that's why you have all the tech trying to make it easier to scale and maintain. That's not to say backend doesn't have it's own difficulties. It all depends what you are making too. A website is easy, a complex app is much more difficult.
Why are you assuming I am a backend dev? In fact why do you even assume I do web dev? You do know that there are many more areas where programming is needed, right?
How I took that is you just don't want to commit to your own statements, so you speak through these "others"...
And backend isn't just web. I was using a catch-all to call out how, misinformed, ignorant, and offensive your statement was.
I didn't make anything up. I just noticed that frontend devs were being looked down upon when talking to some devs and I investigated further. It seems that most frontend devs are just what is usually called "code monkeys" who just fling shit until it works. No real understanding of math, algorithms, architecture and general good engineering principles. Which is also why usually frontend code looks like garbage. I am sure there are exceptions but for the most part frontend stuff doesn't get the best and brightest people working on it. Because it's considered boring and uninteresting. Personally I don't care. Web dev in general seems to be complete and utter trash and I work on things that are on a completely different plane of complexity (as in if things go wrong people die). It's just funny that you still cling on to the idea that frontend is some sort of holy grail of engineering and absolute complexity.
Every engineer I’ve known who’s “looked down” on frontend or was dismissive of it was not only bad at frontend and didn’t understand what it takes to be good at it, but also a jerk about the perceived depth of their own knowledge.