3 ms·

I spent the first twenty years of my career as an embedded systems engineer and there are two specific advantages I gained from that experience: 1) When your w

by smoyer 11y ago

I spent the first twenty years of my career as an embedded systems engineer and there are two specific advantages I gained from that experience: 1) When your writing code for an underpowered microcontroller, you have a plan before you start. This plan includes execution speed and memory usage targets. 2) When you're sending thousands (hundreds of thousands or millions) of non-reprogramable devices into the field, you have a test plan (and comprehensive test suite) that guarantees correctness and performance. Do you know your "machine"? For instance, if you're working with a language that runs on the JVM have you read the JVM specification? (It's the equivalent of your micorcontroller's data-sheet). The part of this manifesto I agree with is that you should thoroughly understand everything "beneath" your application.

logicallee 11y ago
>The part of this manifesto I agree with is that you should thoroughly understand everything "beneath" your application. Say someone (a full-stack developer if you want, or jack-of-all-trades-master-of-none) uses Photoshop and Illustrator but also is coding against Firefox, Chrome, and Safari, and their stack includes node.js, Express, Angular, and PostgreSQL. At some point, you can't thoroughly understand every cycle of every rendering engine. (Which is what what you've stated implies.) It is quite literally impossible - as in, a physical impossibilitiy, of "thoroughly understanding everything 'beneath' your application." You just can't - there are not that many hours in the day. You would have no application left. If you froze technology today you could thoroughly understand all of the mentioned technologies in 10 years. But by then there would be new technologies. Instead, you just have to abstract it away, code against some framework that compiles down to javascript, and only understand that. You can't thoroughly understand every single thing your databse engine is doing either. Otherwise you can just never get anything done. The modern world is made up of applications whose combined reference materials total without exaggeration millions of pages of text. You just can't read a million pages of text. This is completely different from a single microcontroller's architecture. Which is basically a single layer. On the web, even your target is a collection of competing browsers. Why should someone building a front-end site but also using the basics of a database somehow, take months out of his or her life to gain a deep understanding of every cycle of that database engine or what exactly it's doing? What does it get them? Cycles - even billions of cycles - are cheap. It's like asking a farrier[1] (someone who cares for horse's hooves and then puts shoes on them) to learn all the intricacies of metallurgy, really go back to where metal is mined in ores. Oh, and since, "A farrier combines some blacksmith's skills (fabricating, adapting, and adjusting metal shoes) with some veterinarian's skills (knowledge of the anatomy and physiology of the lower limb)" I suppose this farrier suddenly needs to be a complete veterinarian and really fully understand all layers of the horse? It just doesn't work that way. At some point the farrier has to work with an abstraction, and not know what is going on at lower layers, and at some point the full stack developer has to just use an interface that compiles down to javascript that will access a database he or she doesn't know. While you may lament this, beautiful and functional sites have been built this way. It's not fair to ask someone to fully understand everything. Even as a microcontroller coder, you didn't understand the circuitry in the microcontroller at an electrical level - you didn't even get the diagrams. You, too, worked with an abstraction. [1] https://en.wikipedia.org/wiki/Farrier https://en.wikipedia.org/wiki/Farrier
- falcolas 11y ago
  You might be surprised at the depth of knowledge your average Farrier has about both horses and blacksmithing. They might not have a degree in metallurgy, but you can bet they understand the crystalline structures of iron, and how to use that to their advantage. You can also bet on them knowing more about the hooves and related structures of a horse much better than your average vet. The problem with your hypothetical worker is a lack of depth into any one topic. If they're half artist and half front-end developer and half back-end developer, of course they're not going to be able to get into great depth on any one topic. I firmly believe in the value of such a Jack-of-all-trades, but I'd be silly to not value the full time artist who can create better works in a third of the time, because they understand their tools and their craft.
  - logicallee 11y ago
    Yes, it takes three times as long for a jack of all trades to draw something that is a tenth as good as what a full-time artist can do in minutes. A tenth as good isn't good enough. But on the web, for many parts of the stack, a tenth as good really is enough. Even using too many cycles by a factor of three orders of magnitude is still good enough. You just don't need to know.
- smoyer 11y ago
  I never said you had to deeply understand your tool-chain ... the use of Photoshop isn't at all relevant (though understanding the produced image format might be). PostgreSQL on the other hand becomes a lot more powerful the more you learn about how it works "beneath the covers". Of course there are limits ... I knew the timing of my microcontroller's signals but ignored details of the physics behind the microcontroller's implementation. The first computer I built was a COSMAC Elf (based on an RCA 1802 microprocessor) - I didn't have billions of cycles so there was a limit to the work I could do. Now I do have billions of cycles and do my best to make sure there's a linear increase in the amount of work I can do. <old-guy-voice>In the old days, we spent large amounts of time reading data-sheets, specifications and application notes - probably more than we spent writing software. What you're implying is that you're too impatient to do engineering but you're willing to be a programmer (or hacker).</old-guy-voice> So I agree with the premise that we should be producing smaller, faster and less buggy software than we are. I don't think we need everything related to our systems - I certainly used ICE when available to avoid the code/burn/test cycle required using EPROMs. There is (of course) a finite limit to what we can learn, but that doesn't mean we shouldn't want to know everything. One important skill is being able to discern what you need to know, what you need to understand and what you can safely ignore - this is hard. Knowing is also a choice. I can learn more than most because I don't watch TV or spend inordinate amounts of time wasting elsewhere (I have a few vices like HN).
iamcurious 11y ago
>you have a test plan (and comprehensive test suite) that guarantees correctness and performance. I value the work you do, but please don't imply that tests can guarantee correctness. Tests can never prove the absence of bugs! To guarantee correctness we need to treat programs as mathematical objects.

by smoyer 11y ago

logicallee 11y ago

>The part of this manifesto I agree with is that you should thoroughly understand everything "beneath" your application. Say someone (a full-stack developer if you want, or jack-of-all-trades-master-of-none) uses Photoshop and Illustrator but also is coding against Firefox, Chrome, and Safari, and their stack includes node.js, Express, Angular, and PostgreSQL. At some point, you can't thoroughly understand every cycle of every rendering engine. (Which is what what you've stated implies.) It is quite literally impossible - as in, a physical impossibilitiy, of "thoroughly understanding everything 'beneath' your application." You just can't - there are not that many hours in the day. You would have no application left. If you froze technology today you could thoroughly understand all of the mentioned technologies in 10 years. But by then there would be new technologies. Instead, you just have to abstract it away, code against some framework that compiles down to javascript, and only understand that. You can't thoroughly understand every single thing your databse engine is doing either. Otherwise you can just never get anything done. The modern world is made up of applications whose combined reference materials total without exaggeration millions of pages of text. You just can't read a million pages of text. This is completely different from a single microcontroller's architecture. Which is basically a single layer. On the web, even your target is a collection of competing browsers. Why should someone building a front-end site but also using the basics of a database somehow, take months out of his or her life to gain a deep understanding of every cycle of that database engine or what exactly it's doing? What does it get them? Cycles - even billions of cycles - are cheap. It's like asking a farrier[1] (someone who cares for horse's hooves and then puts shoes on them) to learn all the intricacies of metallurgy, really go back to where metal is mined in ores. Oh, and since, "A farrier combines some blacksmith's skills (fabricating, adapting, and adjusting metal shoes) with some veterinarian's skills (knowledge of the anatomy and physiology of the lower limb)" I suppose this farrier suddenly needs to be a complete veterinarian and really fully understand all layers of the horse? It just doesn't work that way. At some point the farrier has to work with an abstraction, and not know what is going on at lower layers, and at some point the full stack developer has to just use an interface that compiles down to javascript that will access a database he or she doesn't know. While you may lament this, beautiful and functional sites have been built this way. It's not fair to ask someone to fully understand everything. Even as a microcontroller coder, you didn't understand the circuitry in the microcontroller at an electrical level - you didn't even get the diagrams. You, too, worked with an abstraction. [1] https://en.wikipedia.org/wiki/Farrier https://en.wikipedia.org/wiki/Farrier

falcolas 11y ago
You might be surprised at the depth of knowledge your average Farrier has about both horses and blacksmithing. They might not have a degree in metallurgy, but you can bet they understand the crystalline structures of iron, and how to use that to their advantage. You can also bet on them knowing more about the hooves and related structures of a horse much better than your average vet. The problem with your hypothetical worker is a lack of depth into any one topic. If they're half artist and half front-end developer and half back-end developer, of course they're not going to be able to get into great depth on any one topic. I firmly believe in the value of such a Jack-of-all-trades, but I'd be silly to not value the full time artist who can create better works in a third of the time, because they understand their tools and their craft.
- logicallee 11y ago
  Yes, it takes three times as long for a jack of all trades to draw something that is a tenth as good as what a full-time artist can do in minutes. A tenth as good isn't good enough. But on the web, for many parts of the stack, a tenth as good really is enough. Even using too many cycles by a factor of three orders of magnitude is still good enough. You just don't need to know.
smoyer 11y ago
I never said you had to deeply understand your tool-chain ... the use of Photoshop isn't at all relevant (though understanding the produced image format might be). PostgreSQL on the other hand becomes a lot more powerful the more you learn about how it works "beneath the covers". Of course there are limits ... I knew the timing of my microcontroller's signals but ignored details of the physics behind the microcontroller's implementation. The first computer I built was a COSMAC Elf (based on an RCA 1802 microprocessor) - I didn't have billions of cycles so there was a limit to the work I could do. Now I do have billions of cycles and do my best to make sure there's a linear increase in the amount of work I can do. <old-guy-voice>In the old days, we spent large amounts of time reading data-sheets, specifications and application notes - probably more than we spent writing software. What you're implying is that you're too impatient to do engineering but you're willing to be a programmer (or hacker).</old-guy-voice> So I agree with the premise that we should be producing smaller, faster and less buggy software than we are. I don't think we need everything related to our systems - I certainly used ICE when available to avoid the code/burn/test cycle required using EPROMs. There is (of course) a finite limit to what we can learn, but that doesn't mean we shouldn't want to know everything. One important skill is being able to discern what you need to know, what you need to understand and what you can safely ignore - this is hard. Knowing is also a choice. I can learn more than most because I don't watch TV or spend inordinate amounts of time wasting elsewhere (I have a few vices like HN).

iamcurious 11y ago

>you have a test plan (and comprehensive test suite) that guarantees correctness and performance. I value the work you do, but please don't imply that tests can guarantee correctness. Tests can never prove the absence of bugs! To guarantee correctness we need to treat programs as mathematical objects.