[rbongers]

I definitely agree about how it may appear to young programmers that they're casting magic spells. I had the fortunate experience early on of building my own virtual CPU and RAM, then I learned assembly, then C, then algorithms, then OSes, then about Unix. I'm not trying to toot my own horn, I've always been a little slow and struggled through this material. However, learning from the bottom up has granted me a lot of insight into how things work and an ability to learn pretty much anything software development related. SCIP has a different approach to "bottom-up" learning than I took but I think it still applies. Maybe with all the tools out there not every programmer needs to learn from the bottom up, but someone needs to learn how everything works to build good tools, and if you can't learn that from MIT, I don't know where.

[IshKebab]

I disagree. The only reason modern computing can exist is because of layered abstraction. You don't need to understand the details of JPEG to write a computer game. You just cast the `jpeg.open()` spell.

Can you imagine if web developers needed to understand everything about how computers work. You must learn how a full adder works before you can use `+`. Oh and you'd better learn about resynchronization before you start using that SoC you bloody amateur!

I imagine everyone draws the "you should know the details about how this works" line juuust below the level that they know about.

[doublepg23]

> I imagine everyone draws the "you should know the details about how this works" line juuust below the level that they know about.

Yes this is usually what I see in tech spaces. I believe discovering _where_ that point is is largely moot and instead the focus should be on _having the ability_ to drop abstraction layers. Some day you’ll find a bug O(n!) and it may just be in a layer or two below.

[rbongers]

I think the other reply to my post is on to something when they say there are many paths to mastery. I have just laid out one path. I don't know what the ideal general learning path is, but I know what worked for me. There is certainly a level where you gain enough knowledge to remove magical thinking entirely and you "learn how to learn", and there's no one way to reach that. I have not seen anyone reach that level by learning only specific abstractions, but I can only talk about my own experience.

I also don't think every programmer needs to follow this kind of path. All I'm saying is someone has to write "jpeg.open()" in the first place.

[IshKebab]

> All I'm saying is someone has to write "jpeg.open()" in the first place.

Of course but my point is that where do you stop? Someone had to design a multiplier. Someone had do invent a diode.

The point at which you say "I don't really care about the level of abstraction below this" is more or less arbitrary. Knowing more is better of course, but there isn't really any level that you have to know.

[rbongers]

I would just expect MIT, of all places, to go quite low. I suppose everything has to come to an end, and MIT can't have the most intensive course forever. I just can't help but feel it's representative of what's happening everywhere.

[IshKebab]

Yeah you have a point. I would hope they have a more introductory module available first but I feel like SICP should be an advanced module for people specifically doing compsci. (I have no idea how American unis work; maybe it's already like that.)

I definitely remember when I did an engineering degree at Cambridge they had us doing assembly and typing decimal opcodes into a numberpad on an ancient microcontroller dev kit. I understood it but it sure was tedious and off-putting. And I say that as a typical HNer who has programmed forever and I even ended up doing CPU verification professionally. I imagine everyone else absolutely hated it.

[emodendroket]

Intuitively I find this view compelling, but I suppose it is somewhat arbitrary. After all, you can start in on integrated circuits and go many layers deeper from there to fundamental physics. And at the same time, we keep moving to higher and higher levels of abstraction with their own complexities to worry about and that's where most will end up working. Maybe the same curriculum doesn't quite make sense.

[rbongers]

I think it's very hard to use an abstraction effectively if you don't know why it exists and you think it's magic.

I have seen programmers who don't understand, for instance, how key/value stores are implemented, come up with all kinds of improbable explanation about what might be happening to their code when it goes wrong, because they blame the data structure. Perhaps they even know the old idiom "don't blame your tools", but they've reached the end of their knowledge - something must be going wrong because of that magic data structure. Meanwhile, it's some kind of side effect they missed. Magical thinking. Sure, they learn eventually what to do when something goes wrong with that data structure, but they come right back to the same problem with everything they don't understand. Taking the magic out of anything, even if not always directly used, is extremely powerful.

I didn't say this before but I also have experience down to the level of designing and building circuits. I think the bottom-up model falls apart here because thinking about the physical properties of electronics is much, much harder than just dealing with idealized logic gates. You can learn it later, but its application is extremely specialized in my opinion.

I don't know, maybe I am biased because of my learning path, maybe students don't need to go as deep, but I can't help but feel that if I did it anyone can.

[inimino]

I have always claimed that the best way to understand regexes is to implement them yourself. This goes for hashmaps and other basic data structures as well. In general this advice has been very poorly received.

Going to the lower level (building the digital from the electronic) is to cross a much more hermetic abstraction boundary, perhaps this is why it's less broadly useful.

[inimino]

> building my own virtual CPU and RAM, then I learned...

Sounds like you know exactly where :-)

Being committed to a project or goal for a long time, taking your time with the foundational material, seems to be the most direct path to mastery in any field.

[rbongers]

The problem is not the learning path doesn't exist, the problem is finding it and knowing if you should follow it. When you get started, you don't know what you don't know.

That's why I say I got lucky... I somehow found this learning path and decided to follow it without really knowing if it would be useful.

Yes, I think that dedicating yourself to any project for a long time will teach you a lot, but you can also end up with a lot of holes in your knowledge depending on the path that you take.

For instance, the most common mistake I see people make regarding learning programming is focusing too much on specific languages and frameworks and never learning anything that could be called fundamentals.

I suppose that's what this is really about. Fundamentals versus specifics.

[inimino]

The trick should be how to set things up so other people get lucky in the same way.

I could give you the same sequence of projects and goals I had as a curriculum, and it wouldn't work for you.

As an individual, if you follow this path, I think the answer is to continually be going back to fundamentals, because they will never stop being an inexhaustible font of inspiration for new ideas.

[rbongers]

You bring up good points. In my opinion it's difficult to put together any kind of significant curriculum, and it's inevitable that it's not going to work for everyone and some people are going to struggle with it. However, there's probably some tipping point where the material just doesn't work for anyone.

I don't know how to account for that. I don't know what the curriculum should be, or how to make it more digestible. I just know that, as as person who hires other programmers and got a taste of both a software development program and my own self learning, I don't like what schools are putting out, and MIT's change in course material seems to be a drastic turn in that direction.

[inimino]

I am coming to the uncomfortable conclusion that organizational habits (hiring and promotion practices, VC preferences for engineering team structures, etc, etc) are more significant than what universities teach (or perhaps, ultimately, the former determine the latter) and we need a movement towards professionalization, and probably some kind of guild-like structure to gatekeep (that is, establish a competency floor) if there is to be any improvement over the status quo. Andrei Sorin's recent massive tome, though a bit of a rant, influenced my thinking quite a bit here.

[rbongers]

That's an interesting idea, I'll give it a read. The big problem I see right off the bat is lack of available talent and hiring pressure, but I reserve my judgement.

[zozbot234]

> I had the fortunate experience early on of building my own virtual CPU and RAM, then I learned assembly, then C, then algorithms, then OSes, then about Unix.

I suppose what's missing from that experience is the reality of programming "in the large", where modularizing code and creating well-defined interface boundaries becomes quite critical. The easiest step forward coming from C would be learning something like Rust - or, historically, C++. This is when the broad high-level patterns and approaches that SICP discusses at length in a theoretical way become practically useful.