I totally agree with you. There is a deeper problem I think across the board, whether it is electronics books or programming tutorials, mechanical engineering, etc. For example, no one teaches you the way you see in this particular segment of an old EEVBlog episode [1]. Please watch this clip as Dave dives deep into how a simple 555 chip works at the transistor level, breaking down into modules and explaining how each module works.
What we need is a book that does the following: Break down REAL circuits from the wild, explain each module in isolation, then explain how it fits into the larger system. No one does this, not in my 15 years of experience in engineering. It is the same everywhere regardless of the subject, teaching is difficult thing to master. 3Blue1Brown is a rare exception, a unicorn of a guy. Richard Feynman's physics lectures are also an example.
Programming books are littered with content pages that list: 1. Variables, 2. Loops, 3. Conditionals, 4. Strings, 5. Functions, 6. Objects,..I am already asleep. YAWN. This is a wrong way to teach people how to program. I couldn't emphasize it enough. Most people won't remember what all these things are and they'll lose interest as they grind through this mindless mess of syntax that they have never seen before.
Instead programming should be taught by building a goal to automate something. Start out by hard coding everything, then introduce variables. Add functions to make your code modular. Then introduce objects, etc. As you build through a program...a real fricking program! with a real goal!.
> For example, no one teaches you the way you see in this particular segment of an old EEVBlog episode [1].
That's odd. EE students in any ABET-accredited program should be formally trained to identify discrete analog design patterns like this without the aid of functional outlines. I know I was (even if I don't design analog circuits for a living). It's also standard practice in industry to segement a given system into simpler functional blocks as a first step in any analysis, discrete analog or VLSI alike.
Like an experienced developer who can often infer design intent by looking at a few lines of well written code, so too can a professional analog designer with circuits that look like magic to the untrained eye.
Maybe I’m not experienced enough, but my ability to do that successfully and rapidly varies dramatically based on a very subjective “how good the schematic was drawn”. Some schematics I look at an easily identify “that’s an input diff pair with current mirrors”, “that’s the gain stage”, “that’s an AB biased output stage”, etc etc. And some are... inscrutable.
My “one trick” though is that I have a drawer full of different coloured highlighters. When I encounter a “badly drawn” schematic, I pull out the highlighters and start colouring the nodes in the circuit and working through what functions each part may serve. One common thing I’ve seen, which I consider very sloppy, is that a circuit can still be made up of common topologies, but the designer didn’t put a lot of effort into making them look like their textbook versions; they realize “I need 4 resistors, a transistor, and a diode”, plop those down, and then draw wandering connections between them. It’s still correct and functional, but not very ergonomic for the user. Sometimes the parts are a long way from each other with big long nets drawn between them (or worse! Labelled nets that don’t actually draw a full line)
And writing all of this, I’ve realized that it’s exactly the same as code. High cohesion and loose coupling and all that :)
>One common thing I’ve seen, which I consider very sloppy, is that a circuit can still be made up of common topologies, but the designer didn’t put a lot of effort into making them look like their textbook versions; they realize “I need 4 resistors, a transistor, and a diode”, plop those down, and then draw wandering connections between them. It’s still correct and functional, but not very ergonomic for the user
Very true. This is exactly like spaghetti code and very hard to make sense of for somebody lacking experience.
>What we need is a book that does the following: Break down REAL circuits from the wild, explain each module in isolation, then explain how it fits into the larger system.
Exactly! As an example, textbooks give the schematic for RC/RL/LC/RLC circuits and their functionality in a isolated manner. But in a real-world product they are amongst a whole other mass of modules and probably drawn badly in a schematic. How do i identify these combinations, infer their input/output and make sense of the overall PCB functionality? I would imagine this knowledge would be most practical and useful in the real-world.
What about 'The Art of Electronics', by P.Horowitz and W.Hill? Not only it goes through many real circuits and systems, it has questions like: 'What is wrong with this circuit?' at the end of every chapter. It is a bit light on math (which in my view is a weakness) but has a lot of engineering insight.
What we need is a book that does the following: Break down REAL circuits from the wild, explain each module in isolation, then explain how it fits into the larger system. No one does this, not in my 15 years of experience in engineering. It is the same everywhere regardless of the subject, teaching is difficult thing to master. 3Blue1Brown is a rare exception, a unicorn of a guy. Richard Feynman's physics lectures are also an example.
Programming books are littered with content pages that list: 1. Variables, 2. Loops, 3. Conditionals, 4. Strings, 5. Functions, 6. Objects,..I am already asleep. YAWN. This is a wrong way to teach people how to program. I couldn't emphasize it enough. Most people won't remember what all these things are and they'll lose interest as they grind through this mindless mess of syntax that they have never seen before.
Instead programming should be taught by building a goal to automate something. Start out by hard coding everything, then introduce variables. Add functions to make your code modular. Then introduce objects, etc. As you build through a program...a real fricking program! with a real goal!.
[1] https://youtu.be/U6qZPx4uD0g?t=2344