> I can't go doing a depth-first search through all knowledge all the time No-one can, not even the author. What we have to understand is: 1) Which componen

> I can't go doing a depth-first search through all knowledge all the time No-one can, not even the author. What we have to understand is: 1) Which components exist. Can't understand what you don't know exists. 2) How those components interface, at a high level. Once you know which black boxes exist and how they are interconnected, you may then choose to open them. For instance, we know that a keypress is detected by the keyboard and sent to the computer, and it will eventually appear somewhere (graphical terminal?). Do we need to know how the wiring works? Only if we want to understand why multiple simultaneous keypresses don't always work. Do you need to understand how information is encoded? Or how the USB protocol works (assuming it's USB)? Or what are keyboard interrupts, and so on. You'll end up learning about font rendering starting from a keypress. You may not need to know how these things work, but it's useful to know they are there, so you can easily find information when you need to. You are more likely to worry about terminal escape codes rather than keyboard wiring, but still. That goes for anything else. Do you need to worry how compilers work? Maybe not. But a high level understanding is important, so you won't immediately say stuff like "language X is faster than Y because it's compiled". Yeaahh, sure, it's possible that it is true. Since we know what compilers do, and they are not a magical "get faster code box", we'll probably say... "it depends, I don't know. Let's benchmark/disassemble/etc".