People learn by doing. There's a reason that "do the textbook problems" is somewhat of a meme in the math and science fields - because that's the way that you learn those things.

I've met someone who said that when he get a textbook, he starts by only doing the problems, and skipping the chapter content entirely. Only when he has significant trouble with the problems (i.e. he's stuck on a single one for several hours) does he read the chapter text.

He's one of the smartest people I know.

This is because you learn by doing the problems. In the software field, that means coding.

Telling yourself that you could code up a solution is very different than actually being able to write the code.

And writing the code is how you build fluency and understanding as to how computers actually work.

> I never did any meaningful amount of assembler programming. It was mostly no longer a relevant skill by the time I studied computer science (94-99). I built an interpreter for an imaginary CPU at some point using a functional programming language in my second year.

Same thing for assembly. Note that you built an interpreter for an imaginary CPU - not a real one, as that would have been a much harder challenge given that you didn't do any meaningful amount of assembly program and didn't understand low-level computer hardware very well.

Obviously, this isn't to say that information about how a system works can't be learned without practice - just that that's substantially harder and takes much more time (probably 3-10x), and I can guarantee you that those doing vibecoding are not putting in that extra time.

I don't know that it's all these things at once, but most people I know that are good have done a bunch of spikes / side projects that go a level lower than they have to. Intense curiosity is good, and to the point your making, most people don't really learn this stuff just by reading or doing flash cards. If you want to really learn how a compiler works, you probably do have to write a compiler. Not a full-on production ready compiler, but hands on keyboard typing and interacting with and troubleshooting code.

Or maybe to put another way, it's probably the "easiest" way, even though it's the "hardest" way. Or maybe it's the only way. Everything I know how to do well, I know how to do well from practice and repitition.

Indeed, a lot of us looked with suspicion and disdain at people that used those primitive compilers that generated awful, slow code. I once spent ages hand-optimizing a component that had been written in C, and took great pleasure in the fact I could delete about every other line of disassembly...

When I wrote my first compiler a couple of years later, it was in assembler at first, and supported inline assembler so I could gradually convert to bootstrap it that way.

Because I couldn't imagine writing it in C, given the awful code the C compilers I had available generated (and how slow they were)...

These days most programmers don't know assembler, and increasingly don't know languaes as low level as C either.

And the world didn't fall apart.

People will complain that it is necessary for them to know the languages that will slowly be eaten away by LLMs, just like my generation argued it was absolutely necessary to know assembler if you wanted to be able to develop anything of substance.

I agree with you people should understand how things work, though, even if they don't know it well enough to build it from scratch.