4 ms·

I doubt you have complete understanding though. Do you understand how SSL works? Do you know your way around PHP's internals? Do you know exactly how TCP, IP,

I doubt you have complete understanding though. Do you understand how SSL works? Do you know your way around PHP's internals? Do you know exactly how TCP, IP, Ethernet, etc work? Could you write a Photoshop plugin? Do you understand how parsers and compilers work? I doubt you (or anyone else for that matter) could answer yes to all those questions. That's the point I think this blog post is getting at. It's no longer possible (question for the reader: was it ever possible, given how deep the rabbit hole goes?) to have a complete understanding of how all the technologies you use every day work. A lot of people have a decent understanding of most things they need to deal with. That's probably good enough to get by.

wladimir 15y ago
was it ever possible, given how deep the rabbit hole goes? I don't think so. People have always complained that the more you know, the more you realize you don't know. But lately we're more and more confronted with our limitations as humans. There are so darn many details, so much information. And no field is static, it's hard to keep up. As programmers/software engineers we're required to have a lot of specific product knowledge. And much of it is very important at one point, and nearly useless the next moment, as new versions are released, as new systems replace the older ones, and old assumptions are overturned.
masklinn 15y ago
> was it ever possible, given how deep the rabbit hole goes? You probably couldn't handle the breadth of it, but the depth of computing in the 60s was pretty shallow. You had maybe a dozen levels of (pretty shallow) abstractions, even "higher-level" languages (like Fortran) were pretty uncommon, so you mostly had assembly, an assembler, machine code and the hardware you were running on. You probably couldn't hold the whole machine in your head, but you could hold a good idea of its cross-section.
- kruhft 15y ago
  I was programming GameBoy about 10 years ago, and it was an amazing machine. You literally could hold the entire machine in your head when writing assembler code. It really let you push the machine to its limits, right down to the clock cycle.
  - masklinn 15y ago
    > It really let you push the machine to its limits, right down to the clock cycle. This is still commonly done for video game consoles (although it's significantly harder), especially late in the cycle when the console's hardware is well understood and its behavior is mapped, in order to wring every bit of performance out of the machine. Probably not to the point it was in the 16bit era and earlier, but it's one of the "edges" consoles have over the PC's raw power.

wladimir 15y ago

was it ever possible, given how deep the rabbit hole goes? I don't think so. People have always complained that the more you know, the more you realize you don't know. But lately we're more and more confronted with our limitations as humans. There are so darn many details, so much information. And no field is static, it's hard to keep up. As programmers/software engineers we're required to have a lot of specific product knowledge. And much of it is very important at one point, and nearly useless the next moment, as new versions are released, as new systems replace the older ones, and old assumptions are overturned.

masklinn 15y ago

> was it ever possible, given how deep the rabbit hole goes? You probably couldn't handle the breadth of it, but the depth of computing in the 60s was pretty shallow. You had maybe a dozen levels of (pretty shallow) abstractions, even "higher-level" languages (like Fortran) were pretty uncommon, so you mostly had assembly, an assembler, machine code and the hardware you were running on. You probably couldn't hold the whole machine in your head, but you could hold a good idea of its cross-section.

kruhft 15y ago
I was programming GameBoy about 10 years ago, and it was an amazing machine. You literally could hold the entire machine in your head when writing assembler code. It really let you push the machine to its limits, right down to the clock cycle.
- masklinn 15y ago
  > It really let you push the machine to its limits, right down to the clock cycle. This is still commonly done for video game consoles (although it's significantly harder), especially late in the cycle when the console's hardware is well understood and its behavior is mapped, in order to wring every bit of performance out of the machine. Probably not to the point it was in the 16bit era and earlier, but it's one of the "edges" consoles have over the PC's raw power.