Electronics Course (45 episodes, YouTube)

There is an artificial hierarchy here but it’s not the one you’re thinking of. It’s a hierarchy of abstractions. At the lowest level of abstraction you’re dealing with physics, Maxwell’s equations, materials and their properties. Above that you have the lumped matter abstraction (conductors, resistors, capacitors, inductors, diodes, transistors). Above that you have modular circuit components, ICs, digital logic. Above that you have CPUs, instruction sets, assembly language… This abstraction continues all the way up through software engineering.

The reason Dave makes this distinction is not because he wants to gatekeep. It’s because he wants people to learn how to build their own circuits rather than combining modules built by others. This is no different from a programmer telling someone to learn a programming language to build their own software rather than using Microsoft Office etc.

Dave does plenty of embedded programming himself. He uses Arduinos when the project calls for them. He just wants people to understand that there’s a whole lot more to understand when you go to a lower level of abstraction (lumped matter components).

I think it’s also an important distinction to be made because a lot of businesses have sprung up within the Arduino ecosystem and it’s brought a lot of new people into the electronics world. These folks are excited and enthusiastic but they often lack knowledge of electronics fundamentals and so they struggle to troubleshoot when things go wrong. It’s important to help these people find the resources they need to learn electronics so they don’t need to rely on others to troubleshoot their circuits.

I see a parallel between the Arduino/Adafruit folks and the people who go through developer bootcamps. It is extremely ill advised to make sweeping statements about bootcamp grads which might imply a shallow depth of understanding or troubleshooting capacity, because so many people will get very upset about your gatekeeping. That vibe hasn't made its way to the EE world, clearly.

I've had a 35 year and counting career as a self-taught software developer. I've learned a lot about adjacent concepts without needing to become particularly expert in any of them, because I learned early to delegate to others' strengths. For example, I've never learned assembly or been unable to function because I couldn't implement a device driver. I also have very weak math skills in general.

All of which brings me to the actually important question: what knowledge or skills do you need to do what you have set out to do? An honest evaluation of most problems can only result in "not that much, actually" because you are not working in a vacuum. We have YouTube and GPT. We make friends with complimentary skills, and we develop a sense of when to persist vs when to ask for help.

I don't subscribe to the idea that someone who has internalized all of the formulas is somehow more pure, any more than I assign respect to someone who still memorizes all of their friends' phone numbers.

In many/most cases, not knowing which topics we should obtain deep knowledge of is actually a negative. While it's perfectly reasonable to decide that you want to know all about Maxwell's equations, but you should see it for what it is: a hobby, unless you have a damn good reason to prioritize it over something silly like shipping your project.

It's like the DIY keyboard community, I guess: it's cool that folks want to get that nerdy about building their own data input device... but if you stop to build your idea of the perfect keyboard before starting the task assigned to you, you deserve to be given a strike.

TL;DR: 98% of people with a deliverable in mind would be better suited by a Collin's Lab video than a 45 minute lecture on the physics that make capacitors work.