Comment by dmlorenzetti | Hacker News Reader

Comment by dmlorenzetti | Hacker News Reader

I did an electrical engineering course. Especially with hardware ("welcome to tweak week"), there was a real sink or swim approach. I ended up feeling like it had to do with testability. It's easy to grade a test if you just look for right answers, and mark everything else off. It's easy to grade labs if you just look for the circuit tracking the input frequency. Grading either based on some assessment of how well the student understands what's actually happening is much, much harder.

My older brother and I went through the same classes and labs together. He brought to the table 15 years of experience playing around with electronics, so when we took labs, he had a clear sense of how to debug hardware.

He would wave his hand over some part of the circuit, and make gnomic pronouncements like, "When the input goes over about 5 volts, this part goes apeshit and starts firing back at it." Then he'd swap out a cap or a resistor, and everything would start working. I just went along for the ride.

I had decent math skills, so I did all right in the program. But I never learned that intuitive, heuristic, holistic way of grokking circuits like my brother did. Nor could I ever see that the school had any way to reward people like him, who "got" things at a deep level.

My sense was always that his approach didn't test well. If you test people for calculating the right voltage, you end up rewarding people who "plug & chug" quickly, even if they don't know what the voltage means, or why it would make some cluster of components go apeshit when it goes over about five volts.

> It's easy to grade a test if you just look for right answers, and mark everything else off. It's easy to grade labs if you just look for the circuit tracking the input frequency. Grading either based on some assessment of how well the student understands what's actually happening is much, much harder.

The professor I had for Networks and Linear Systems had an interesting approach to that. He developed every test problem such that the input values were small, whole numbers. If you did the problem right, your answers would also be small whole numbers. If you went off into the weeds, you would get really weird answers. That was both a hint to the student that they were barking up the wrong tree and a guide as to where the solution broke down.

EE is all about intuition, really. If you don't have the intuition to approximate everything (I don't) then you just sink; there's no way to do everything exactly like is often possible in CS. It's even more important than how good you are at math, because the whole point of the skill is figuring out when you don't have to do a lot of math in the first place.

CS is also heavily reliant on intuition:

- Picking the right architecture for a complex system out of a huge space of potential solutions (which have varying costs, performance, reliability, maintainability and complexity) requires a lot of intuition, developed over years of practice. There's no deterministic method that you can use to crank out the "right answer".

- At a lower level, the same applies to choosing algorithms: Will an algorithm that's much simpler to implement but provides reasonable average performance over most of the cases I need to handle be better than a complex algorithm that will take much longer to implement? Are there heuristics that can help me solve a problem that's computationally intractable? The answer frequently comes from intuition.

- When debugging, being able to quickly narrow down the possible causes of bugs (is it a memory leak? a race condition? a compiler bug?) requires a lot of intuition. Yes, it's possible to debug by brute force, but people with an intuition for it can do it much more efficiently.

In addition, usually you are balancing those searches for optimal solutions against business deadlines, incomplete specs, and the need to make unknown changes in the future.

Does anyone have advice for learning this kind of "intuitive, heuristic, holistic way of grokking circuits"?

> 15 years of experience playing around with electronics

Pretty much this. It's a variant of the "10,000 hours rule" http://en.wikipedia.org/wiki/Outliers_%28book%29

I'm like the OP's brother in that when I started EE, I had already been tinkering with circuits for about 7 years. Obviously, in labs it was a huge help, but it also gave the math and all the abstract concepts learned in class some relationship to the real world.

Having the background means you can glance at a circuit and immediately know that a certain resistor is sized too small, or hearing the high-pitched whine of an inductor means that may be the problem with your regulator. In short: build lots of different stuff, have it blow up in your face, and learn something from the experience.

Buy the radio shack 150 in 1 electronics lab. Complete all 150 projects.

In between play with Lego Technics.

Buy all the parts and a breadboard, do 10 projects using solder to make the result permanent.

Do radio shack still edit it ? It does not look like it still does

Sparkfun should propose something similar then :)

This is really close. http://www.amazon.com/gp/product/B00005K2SY?tag=griffindigit...

https://www.sparkfun.com/ - get some toys and start playing. Hands on approach.

What helped for me:

* Play with circuits all day

* Learn to grok math. No, really. Learn to understand the physical meaning behind what you write. Time integral of some signal? Oh, yes! It's energy = ability of that thing to do work. Fourier series => this signal written as a sum of sine signals which you can analyze separately (with all the implications that has for linear systems). That kind of stuff.

* Learn to look at circuits in terms of transformation of magnitude, phase, frequency, shape and nature of signals, not in terms of connections, adapting this to various use cases in circuits. There's no general answer for this; an inductor is sometimes there to "insist on keeping the current to a constant value", sometimes it's there to exhibit a greater impedance to high-frequency signals, therefore allowing -- along with the capacitor over there -- only signals of a certain narrow frequency band to pass.

* Learn circuits in terms of idioms. Try to look at schematics and understand that "this part" is a filter, "that part" is a preamplifier, "that part" is a current mirror used for biasing and so on.

Reading application notes can be helpful . They hold plenty of knowledge and in many cases they are described in a less formal more intuitive way.

The art of electronics has some nice ideas.

1) don't use a calculator. It's easy to plug numbers in without really understanding what they mean, and also believing a number that is several orders of magnitude out. And after the first week of converting between micro and nano and pico you'll have a good grasp on what those numbers mean.

2) draw circuits by hand. You'll be working on small circuits and drawing them is a bit like the "learn whTever the hardway" approach of typing stuff in.

3) for analogue DC circuits it's about manipulating current, voltage, resistance. For ac circuits it's power and impedance. For digital it's 1s and 0s and timing.

3a) in context components serve a role - decoupling or current limiting or amplifying or etc etc. you get to learn the configuration of a few components means an amplifier, and so you know that a voltage across those pins means a bigger voltage across those other pins.

Years ago the advice was to grab some second hand equipement and some new components and a breadboard and make circuits. The eauipment would be a powersupply, an oscilloscope, a signal generator, maybe a multimeter. The components would be a few resistors and capacitors and transistors with so e 555s and 741s. (With a few 4xxx series thrown in). Nowadays there is almost certainly a virtual set of this stuff that you can run on a computer. Perhaps some HN reader is involved in it?

The Art of Electronics (and the Student Lab book) used to be a solid introduction - hard work but good. I'm not sure if there's anything better for general use and I guess there's a lot of dated content. Microcontrollers is one example where you'd want additional books.

Tldr: do it.

Reply on news.ycombinator.com