[scop]

This book was absolutely essential when I was first sinking my teeth into software programming. Things that seemed either arbitrary or completely mysterious suddenly made sense now that I had a contextual understanding of how computers worked. Without having that knowledge, I think my career would have been vastly more difficult and frustrating.

While I understand many “get started programming” books/tutorials put an emphasis on getting coding asap, I really had to stop and learn about computers before I could start coding in a well rounded way (and that’s coming from a WebDev, who doesn’t even have to deal with low-level stuff too often!).

Thank you Mr. Petzold!!!

[unwind]

Uh, as someone with too many years of programming behind me to imagine that, can you mention some concrete things that you found arbitrary or completely mysterious, and that the booked cleared up for you? Thanks.

[percentcer]

I'm not the OP, but some personal examples:

- why is little-end / big-end a thing?

- why is volatile memory called volatile? and why can't we just keep that data around?

- what can a 64-bit computer do that a 32-bit computer can't?

- what do people mean when they say "code is data"

- what's an instruction, really?

- how did people program computers before they had screens?

- how did people program computers before they had keyboards?

- why is it called 2's complement?

And others that I can't recall right now. It's a fantastic book and I recommend it to everyone who is the slightest bit interested in how computers work.

[omnicognate]

> why is it called 2's complement?

And why the apostrophes in two's complement and ones' complement are in different places.

[unwind]

That's a great list anyway, thanks!

[scop]

That's a great question. I started out as a programmer having been a casual computer user through my childhood/teenage years. I never took apart computers or ventured into how they worked. Thus, when I decided to pursue this as a career, I had a lot of catch up to do. Here's a couple of things off the top of my head:

- The terminal was completely foreign to me. Why is it structured so? How are permissions set? Octal?!?!?!

- Why do I have to specify a type in a programming language?

- What/why are all these special characters used in programming?!

- Why is a program structured in the way it is? What are the levels of abstraction working in a given program?

- What happens when I run/compile my program?

I would also say that learning a little bit of C also really helped illuminate computers for me. Not only in the sense of how they work, but also why programs use their current syntax. For example, for developers who look at Javascript for the first time seeing parenthesis, colons, curly brackets, etc all make an initial sense: they seem familiar. However, to somebody first diving in all of these characters seem totally arbitrary! Having gained a sense of how computers worked and then a very basic introduction into low-level programming, suddenly these high level languages seem much less arbitrary.

[unwind]

Thanks for sharing! I can (of course) understand that many of these things seem arbitrary, but would never have been able to come up with the list on my own. :)

[slingnow]

None of these sound like particularly low-level concepts the book is purported to cover.

Like you said, "learning a little bit of C" would probably cover most of the things you listed. It sounds like you're a web developer.

[skripp]

What makes this book great is that it more or less only assumes you know how an on-off switch works. Then he goes on to teach you how a (although rather primitive) CPU works and how you would program it.

The teaching style in this book is so unbelievably good that even if you know all the ins and outs of a computer you want to read on because he explains everything in a way that you wish that you would have come up with yourself.

[jgwil2]

> assumes you know how an on-off switch works.

Really he explains how that works too. It's reasoning from first principles at its finest. I wish school curricula were so well-designed.

[filoleg]

The best and most useful in a long-term classes that i took in college were first-principle-taught classes, even if they weren't directly related to any work i did at the time (or ended up doing in the future).

The one I remember dearly was CS2110 at Georgia Tech. Most undergrads shuddered when they heard of that course and tried to avoid it, but it legitimately opened up my eyes to how computers "really" work. The class started all the way from logic gates, to building your own 8-bit APU using those logic gates (in a simulator), to writing some assembly code, to programming a gameboy game, to implementing your own malloc. And the continuation of that course, CS2200, was great too, which started with using logic gates and basic APUs (the kind you implemented yourself in CS2110) to build a primitive CPU pipeline (in a simulator as well).

I cannot ovestress how useful that understanding (no matter how basic it was) ended up being later on in my career, despite me doing mostly webdev for the first 5 or so years out of college. It basically turned my knowledge from "i know how to write code" to "I understand what I am actually doing on all levels of the stack (even if that knowledge is rather simplistic for the lower levels of that stack)". Came in pretty handy when I discovered a bug in one of the early versions of the TypeScript transpiler as I was writing my webdev code. Pretty certain I would've been completely stumped by my code not working if I didn't have an intuition for digging in that direction (which i definitely wouldn't have had, if it wasn't for that class).

Everything in that class was building up so well off what was learned earlier in the class, I was wowed. I actually felt like i understood how those things were naturally "discovered" for the first time back in the day. Basically, it was the difference between "here is a formula, here is what it does, here is how you should understand it" and "here is what you know, here is a concern you might want to think about next, oh congrats, you just 'discovered' this well-known concept following the same train of logic that led to it being originally 'discovered'".

[jrmg]

I often wonder: for someone with no understanding of how computers work; no idea about electricity and transistors, no idea about CPUs executing instructions, no idea about software and abstraction: what do they think about when they click a ‘play’ button in a music player, and the interface updates and music starts? Do they think about what is happening ‘inside’ the box? I think I do.

I suspect I have a completely different mental model than them - just a completely different casual understanding of it. I find it hard to imagine how they must see the modern world. It must seem like magic!

Note that I’m not at-all speaking about intelligence here. Just knowledge.

Anyway: for that person, I think that if they read ‘Code’, their entire understanding of the world would change, which is sort of amazing.

[pbourke]

> I find it hard to imagine how they must see the modern world. It must seem like magic!

I think this is unnecessarily infantilizing. There are a great many very complex things in the modern world, and people must employ abstractions for most of it.

I think with the rise of multi form factor computing, there is more basic literacy about the nature of computers these days. People don’t think that a phone god makes their phone work and a laptop god lets them work on their document.

[fn-mote]

>> I find it hard to imagine how they must see the modern world. It must seem like magic!

> I think this is unnecessarily infantilizing. [...] people must employ abstractions [...]

"Magic" to me means "does not (appear to) obey laws of cause and effect".

When the phone doesn't work after you install App X, do you attempt to remove app X? Why would restarting the phone help the situation? If none of this is logical, you're just following the 16 step Apple Fixit Checklist, good luck... it might work... but if you miss something what happens? You're just back to the start and run the checklist again... or call the ~~witch doctor~~ knowledgable friend.

Now I won't say there's no magic in understanding computers. There certainly are cause and effect mechanisms that are too arcane for ordinary mortals to be familiar with (even like "don't build the project inside a directory that has a space in it" never mind "don't put a colon or slash in your filename").

The point is: "magic" does not have to mean infantilizing.

[jrmg]

I said ‘like magic’. I know they know they’re made by humans and understandable with effort.

Complex chemistry and materials engineering feels ‘like magic’ to me. I know I could understand it with enough effort - but I don’t understand it now. I’m sure my view of everyday things would change if I did.

[bitwize]

We etch runes into stones, imbue them with lightning, and thereby make them come alive and do our bidding... and you want to tell me computers are not magic?!

[azov]

What's your mental model of a dog?.. What's happening inside when he barks or wags his tail? Why does he like carrots more than cheese? How does his memory work?..

The way you think of dogs is probably not very different from the way many people think of computers.

[dreamcompiler]

It's different for me because I know that computers are knowable because they were built by people, and lots of people (including me) know how they work. I believe dogs are knowable too because I believe in science, but nobody really knows (yet) how dogs work at anything close to the same level of detail.

Lets take something I know nothing about: Industrial chemistry. That still seems less mysterious to me than dogs, because I know that I could find books about industrial chemistry at whatever level of detail I wanted. But dogs--not so much, beyond a rather superficial level.

[thoms_a]

I've asked very young students what they think a computer is and how it works. There's always at least one student who correctly replies: "It's a machine that does what someone told it to do".

Of course modern computing devices are absurdly complex and intricate machines all the way from silicon to software, but the basic mechanism is easily grasped by children. For all their complexity, computers are still just programmable calculators.

[CamperBob2]

There's always at least one student who correctly replies: "It's a machine that does what someone told it to do".

That's correct, right up until someone tells a computer to beat a 9-dan Go master, but not how to do it.

[sixstringtheory]

I didn’t discover it until after coding for over 20 years and getting a masters in cs, and I really enjoyed it for filling in some gaps in my knowledge of the engineering side of things and the historical treatment of how various things came to be. And it was a great review of all the stuff I did already know from formal training and experience. It was a quick and easy read, even after tracing through every schematic, so I found it very enjoyable.

[SkyMarshal]

Same. I think some of us learn best by having a map of the territory and an understanding of how everything all fits together first. Having that better helps us deep-dive into and master specific areas. This one single book provides that map.

[_jal]

Absolutely. I tend to be mystified and lost without some way to place what I'm doing in some larger context, even if that context is super-vague or wrong in technical ways.

Had several teachers who utterly refused to provide that, repeating "it'll all make sense eventually." Well, it did, after I got better teachers.

[scop]

That's a great observation about teachers. I was fully convinced in late middle school that I was an idiot who had no hope to achieve good grades or a grasp of subjects. Then suddenly I found myself getting As in high school without a real change in effort/routines. I attribute that in large part to learning the "why" behind various subjects via new teachers.

[coldpie]

Wish I had something to say other than "me, too." I read it sometime in high school, well after I'd learned C, and it really made me understand what was actually happening to the code I wrote. Very helpful later in my career and hobbies too, when I have to do reverse-engineering.

[Breza]

I'm a big fan of teaching the fun part first, but that really ought to be followed by learning the boring stuff. I think of it as teaching the What followed by the Why. Too many programs seem to stop after the first part.