4 ms·

Yes, it reminded me a lot of when I first started in computing. Today we are so abstracted from the horsepower that produces our experiences, to the extent tha

Yes, it reminded me a lot of when I first started in computing. Today we are so abstracted from the horsepower that produces our experiences, to the extent that most Software Engineers don't actually know how their code works. Not saying that is a bad thing, not saying that it is mandatory, it's just an art and science that is eroding rapidly. I started as an 8yr old, reading computer magazines, and initially coding in BASIC in 1K of RAM. I into Z80 Assembler and Machine Code at 10yrs - learning primitives like NMI's, Display DMA and Sound IO by hand with pencil, paper, and lots of reboot-causing mistakes. It was bruteforce, but still very influential in my understanding of a then-modern computer system. Z80 was a simple-enough chip instruction set that I still remember most the mnemonics today, and many of the architectural principals are still valid even after so much time.

fwip 5y ago
> most Software Engineers don't actually know how their code works. This is only true when you decide that the specific level of abstraction that you learned is the important one. Sure, you knew the machine code. Did you know how the instruction set was implemented on the chip? The decode logic at a transistor logic to set the right signals to route your register to the ALU? Did you care about the equations that governed the flow of electrons through silicon? Or did you trust the machine code to be your level of abstraction that Worked?
- AnIdiotOnTheNet 5y ago
  The world isn't as black and white as "all abstractions bad" or "all abstractions good" though. There are levels of abstraction that are objectively useful and levels of abstraction that are so separated from reality that a 3Ghz multicore computer is somehow incapable of keeping up with a human's typed input.
  - fwip 5y ago
    And the level of abstraction that is "good" changes over time and by use case. At my day job, I write both high-performance bioinformatics software and good-enough-performance web software. I do need to look at the assembly & think about the internals of the CPU when I'm trying to push through billions of reads in a timely manner. But I don't need to count cycles when I'm rendering a CRUD detail page in Django - I just need to make sure my database queries are reasonable. Also, the idea that you can say some abstractions (presumably in wide use) are "objectively" bad only makes sense if you've already applied your subjective criteria.
    - AnIdiotOnTheNet 5y ago
      Like I said, I think it is pretty objectively bad if a 3Ghz computer can't keep up with basic user input. I don't think that's a crazy high bar.
- throw10920 5y ago
  This is a little bit reductionistic. You can slightly the alter the claim to "most software engineers don't actually know how their code works at a level that's relevant for them to make good software" and it becomes solidly true. Most (web) software engineers don't know anything about assembly, CPU cache, virtual memory, or pipelining, and application of knowledge of those things would change web applications from their current abysmal levels of performance to something acceptable. Very, very rarely is knowledge of the microarchitecture, microcode, transistors, or physics necessary to make modern software reasonably correct and performant.
  - deleted 5y ago
    [deleted]
  - fwip 5y ago
    Most software engineers aren't working on something that needs knowledge of CPU caches to reach performance goals. Especially (web) engineers. You can write performant javascript for years without even knowing that CPUs are pipelined, let alone the details. Most of the few software engineers that make their living writing code that needs to be fast, do know the things they need to know to make the code fast. I don't agree even with your altered claim. Most software engineers do know how their code works at the level that they need into order to make good software.
    - akkartik 5y ago
      Oh, that last paragraph. Are you saying the way the world writes software is totally fine? You're entitled to your opinion, but I think that's too big a chasm to bridge in this text box :) I'll just say this: one pattern shared by the best programmers and systems thinkers I've met is that they took the trouble to look under the hood. I really consider this to be a non-saturating metric. The more someone looks under the hood, the better a programmer and systems thinker they are.
    - loxias 5y ago
      > Most software engineers do know how their code works at the level that they need into order to make good software. This kind of thinking is why we can't have nice things! If this were true we would have good software. As the world (currently) exists, we have a vast ocean of horrible software with a small number of islands of quality. I'd argue "most" software engineers don't know enough. The fact that checking my bank balance online involves transferring 32 million bytes of information(!!) over nearly a third of a minute, or that bluetooth headphones have so much latency they're unusable for live music, despite radio waves traveling at the speed of light, or... any app written in electron, ever (or pick any other example of stuff sucking in modern life, it's ubiquitous)... these are all a result of engineers knowing way, way too little about how their stuff works. Most people, including engineers, are idiots, slapping together components and using abstractions they have NO understanding of, stopping at an increasingly low bar of acceptability. (I make no claim to be special or otherwise a "non-idiot".) correction: 5 million bytes of information, not 32. but still at least 4.9 million bytes too many.
- ericbarrett 5y ago
  I would venture that most people who started programming back then were familiar with basic digital circuitry like adders and latches, so probably, in the sense that you might know how an engine works without being able to build one from scratch. RadioShack still sold electronics components. My early 80s alarm clock came with a full schematic.

fwip 5y ago

> most Software Engineers don't actually know how their code works. This is only true when you decide that the specific level of abstraction that you learned is the important one. Sure, you knew the machine code. Did you know how the instruction set was implemented on the chip? The decode logic at a transistor logic to set the right signals to route your register to the ALU? Did you care about the equations that governed the flow of electrons through silicon? Or did you trust the machine code to be your level of abstraction that Worked?

AnIdiotOnTheNet 5y ago
The world isn't as black and white as "all abstractions bad" or "all abstractions good" though. There are levels of abstraction that are objectively useful and levels of abstraction that are so separated from reality that a 3Ghz multicore computer is somehow incapable of keeping up with a human's typed input.
- fwip 5y ago
  And the level of abstraction that is "good" changes over time and by use case. At my day job, I write both high-performance bioinformatics software and good-enough-performance web software. I do need to look at the assembly & think about the internals of the CPU when I'm trying to push through billions of reads in a timely manner. But I don't need to count cycles when I'm rendering a CRUD detail page in Django - I just need to make sure my database queries are reasonable. Also, the idea that you can say some abstractions (presumably in wide use) are "objectively" bad only makes sense if you've already applied your subjective criteria.
  - AnIdiotOnTheNet 5y ago
    Like I said, I think it is pretty objectively bad if a 3Ghz computer can't keep up with basic user input. I don't think that's a crazy high bar.
throw10920 5y ago
This is a little bit reductionistic. You can slightly the alter the claim to "most software engineers don't actually know how their code works at a level that's relevant for them to make good software" and it becomes solidly true. Most (web) software engineers don't know anything about assembly, CPU cache, virtual memory, or pipelining, and application of knowledge of those things would change web applications from their current abysmal levels of performance to something acceptable. Very, very rarely is knowledge of the microarchitecture, microcode, transistors, or physics necessary to make modern software reasonably correct and performant.
- deleted 5y ago
  [deleted]
- fwip 5y ago
  Most software engineers aren't working on something that needs knowledge of CPU caches to reach performance goals. Especially (web) engineers. You can write performant javascript for years without even knowing that CPUs are pipelined, let alone the details. Most of the few software engineers that make their living writing code that needs to be fast, do know the things they need to know to make the code fast. I don't agree even with your altered claim. Most software engineers do know how their code works at the level that they need into order to make good software.
  - akkartik 5y ago
    Oh, that last paragraph. Are you saying the way the world writes software is totally fine? You're entitled to your opinion, but I think that's too big a chasm to bridge in this text box :) I'll just say this: one pattern shared by the best programmers and systems thinkers I've met is that they took the trouble to look under the hood. I really consider this to be a non-saturating metric. The more someone looks under the hood, the better a programmer and systems thinker they are.
  - loxias 5y ago
    > Most software engineers do know how their code works at the level that they need into order to make good software. This kind of thinking is why we can't have nice things! If this were true we would have good software. As the world (currently) exists, we have a vast ocean of horrible software with a small number of islands of quality. I'd argue "most" software engineers don't know enough. The fact that checking my bank balance online involves transferring 32 million bytes of information(!!) over nearly a third of a minute, or that bluetooth headphones have so much latency they're unusable for live music, despite radio waves traveling at the speed of light, or... any app written in electron, ever (or pick any other example of stuff sucking in modern life, it's ubiquitous)... these are all a result of engineers knowing way, way too little about how their stuff works. Most people, including engineers, are idiots, slapping together components and using abstractions they have NO understanding of, stopping at an increasingly low bar of acceptability. (I make no claim to be special or otherwise a "non-idiot".) correction: 5 million bytes of information, not 32. but still at least 4.9 million bytes too many.
ericbarrett 5y ago
I would venture that most people who started programming back then were familiar with basic digital circuitry like adders and latches, so probably, in the sense that you might know how an engine works without being able to build one from scratch. RadioShack still sold electronics components. My early 80s alarm clock came with a full schematic.