I had a similar experience with a family member. When I asked them how their keyboard strokes appeared on the screen, all I got was confused looks. When I showed them that the first thing that happens is a hardware interrupt, her mind was blown.

Seriously, it's okay that people don't know the ins and outs of every little detail. Abstractions are useful, until they're not. And then when they're not, you go figure out the level below.

Even the most advanced, most skilled front-end devs spend 99.99% of their time not caring that the browser loads an HTML page.

I think your analogy would be valid if the previous commenter had, for example, asked their sister-in-law how the browser interprets the JavaScript it receives, or how it builds the display from the DOM. Now that would be asking about irrelevant and unnecessary levels of detail which are best abstracted away. However, knowing that the process starts with the browser receiving HTML over HTTP is essential to understand what's going on, even if you know nothing about the details.

If I may, a truly similar experience regarding keyboards would be this:

I had a similar experience with a coworker. When I asked him how the code that he types appears on the IDE on his screen and not on that of any of our colleagues' screens, all I got was confused looks. When I showed him that his keyboard is wirelessly connected only to his computer, which runs the IDE, and his computer is then specifically connected to his own monitor via a cable, his mind was blown.

It was just a random example, you can literally pick any level in any number of abstraction stacks that exist and make the same analogy.

Sometimes it becomes necessary to know how the level below works. That doesn’t mean it’s a requirement to be affective at the level above.

> That doesn’t mean it’s a requirement to be affective at the level above.

Not necessarily, but it did have a material effect in the original example. A web developer drug in a complex, unnecessary framework because she didn't realize that HTML forms have the ability to submit post and get data natively.

To me that's like a civil engineer building a suspension bridge over a tiny creek because they never heard of an arch design.

> A web developer drug in a complex, unnecessary framework because she didn't realize that HTML forms have the ability to submit post and get data natively.

You're making a massive assumption that she didn't already need to use React and may have been confused at how she would make the two systems work together correctly.

Let me settle this debate: as I originally stated, the young developer was not stupid at all. She knew about HTML and forms and everything. She just didn't know how to work with it and, more importantly, she didn't want to get into that at the time, explaining that she didn't "want the site to look ugly" and that it was "a project for the portfolio" (implying that she needed to demonstrate her React skills).

So that's what's really troubled me. The companies responsible for producing this piece of garbage are actually getting into the heads of the younger generation, rendering them helpless without said garbage. I repeat, this is indeed garbage, especially React: in early 2000s we used to laugh at people mixing JavaScript and HTML, but some of them, apparently, decided it was their time to strike back.

The more important issue is, of course, that we have a generation of young people working with these "tools" which isolate them from learning things that actually matter. These levels of abstraction DO NOT add any value. These are "cargo cults" of abstractions, which without their authors knowledge (because those who invented them weren't very smart anyway) serve the purpose of keeping potentially talented and intelligent people ignorant and average. This is probably good news for somebody out there, but certainly not for us as a society.

> serve the purpose of keeping potentially talented and intelligent people ignorant and average

Man I think you're thinking wayyyyy to deep into stuff.

Agree.

I would add that even good old, rock solid assembler isn't a straight entry point into controlling the CPU, but is now just an abstraction over µOPs. Abstractions surround us these days, and for each of us, we find differing levels of what's tolerable vs what should be known about the next layer below.

I'm personally (kinda) ok with not knowing too much about the sub-assembler processes that happen inside the literal black box called a CPU, but I know that for branch optimisation, it's important.

I would categorize things as "does someone on the team need to know this":

* Why does a key appear on the screen when I push a button on my keyboard: no

* How is an HTTPS connection created: generally no

* How is the JavaScript library deployed: 100% yes

You might be able to throw something together that works without understanding that it is a JavaScript library with a bootstrap HTML page but if no one on your team understand that you will eventually need to find someone that does to solve a problem.

> * How is an HTTPS connection created: generally no

I would think that people doing web development probably benefit from a working knowledge of DNS, TLS, and PKI. Without those, I would expect a lot of readily avoidable problems with HTTPS.

In general I advocate that software engineers should have a functional, if abstract, understanding of how computers work on various levels. They might not need a detailed understanding, but people often benefit in unexpected ways from understanding the systems they work with.

In 2022 that person is ops not dev. None of my devs have any knowledge [1] about TLS, DNS, or even TCP. The only interaction devs have with the messy outside world is Rack/WSGI, their DB ORM, their Queue/Job abstraction, and the AWS client libs.

[1] Not like they literally don’t know but that their code has no interaction with it.

That veil of abstraction gets pierced very quickly the moment you need to debug an issue or regression in your application. I'm working on an internal application that's using Django in my current job, and there are plenty of instances where we've had to run an EXPLAIN on the generated MySQL query to identify performance bottlenecks.

And one eventually figures it out anyway after one too many blank pages on an angular app :D

Not knowing how Angular bootstraps is how you get super huge SPAs that take forever to load on anything that is not a gigabit connection. Technical details matter.

Genuinely do not follow this logic

Man that is really sad, but I suspect these code in the cloud schemes will be targeted toward hordes of developers with such a superficial grasp on what’s happening.

That may say more about her than CS in general. I remember my very first encounter with Angular I made my seniors investigate how the hell double way binding could even work that way to have them confess to me that yes, we had 40k repeating functions running every n seconds to check variable states... for a static website whose double binding was just a first render time convenience. No wonder our mexican clients with shit phones couldnt load the site as well as our iphone-heavy Hong Kong ones. And it was my very first day on Angular.

How can she not be curious, Angular is so wrong and magical, it blows the mind to understand how it builds all that magic. Maybe your sister in law is the kind of persons who laughs at magic tricks ? I d be raging mad myself, I prefer to avoid them or Ill just be obsessed until I understand them

I like an SPA pile on as much as the next person, but I've seen similar ignorance from asp.net webform developers many years ago. Some of those were even "experienced" developers.

To be fair, ASP.NET Web Forms obfuscated the relationship between your code and the HTTP request-response cycle almost as badly as an SPA framework.