And over and over time proves that, when you need it, ASM or C or generals system knowledge was handy. One example, I am not a "Windows" or "NT" guy, mostly working in various Unixes and Linux in my professional career. I had a client who had battered every resource trying to fix some horrible freeze/timeout in their application. So I rolled up my sleeves, first search " is there dtrace on windows", found some profiling tools, found the process was stuck in some dumb blocking call loop, resource was unavailable, and the rest was history.

So yeah i mean - who cares how it works - but also if you have experience in how things _do_ work you can solve problems other people cannot.

Sure, "it's handy" and once every few years you encounter a bug where ASM or C knowledge is valuable.

Yet most programmers nowadays can't write ASM or C and still manage to produce useful software.

I reckon there's a limit to how long this abstraction can go on before not understanding underlying mechanisms will seriously hamstring you.

I think we're a long ways from that.

But with that said, those who learn the underlying mechanisms will always be able to solve more problems than the folks who don't. When you know the lower pieces, your mental model tells you when and where the higher level pieces are likely to break. Legit superpower.

> But with that said, those who learn the underlying mechanisms will always be able to solve more problems than the folks who don't

I would define that as being "seriously hamstrung"

Well how many times have we seen the S3 bucket set to public while the customer data piles up and leaks out to space.

It started before that. When assemblers came out, (some) programmers worried about losing touch with the machine if they didn't have to know the instructions in octal.