111–120 of 132 posts
I never knew this was a problem in EE, but I know for a fact it's a huge issue in CS. They don't want to teach any "tools" b/c CS professors find teaching people how to be good developers as beneath them. They honest to god think CS is an actually hard science on par with math and physics. You can sum up their attitude with: "It's not an associates degree goddamnit!" (even though it should be) Another source of reluc…
The debugger should be a concept to be taught, just like the compiler, linker, interpreter, assembler and so on. There should be at least a few lab hours where students are given existing programs and need to go for a bug hunt. This should include strace and valgrind, two essential tools that will probably not be outdated for quite a while. Now, where I disagree is the IDE part. I have nothing against IDEs per se and…
"Students should learn what those components do from scratch"
Yeah, they will eventually. When they take a compilers class, they'll understand how the compiler works. It's okay to have that be "magic" in the mean time. They should be focusing on learning about OO principles, and data structures, and algorithms and not futzing with command line tools.
I never knew this was a problem in EE, but I know for a fact it's a huge issue in CS. They don't want to teach any "tools" b/c CS professors find teaching people how to be good developers as beneath them. They honest to god think CS is an actually hard science on par with math and physics. You can sum up their attitude with: "It's not an associates degree goddamnit!" (even though it should be) Another source of reluc…
The debugger should be a concept to be taught, just like the compiler, linker, interpreter, assembler and so on. There should be at least a few lab hours where students are given existing programs and need to go for a bug hunt. This should include strace and valgrind, two essential tools that will probably not be outdated for quite a while. Now, where I disagree is the IDE part. I have nothing against IDEs per se and…
I do agree that learning the difference between the editor, compiler, the linker, and various other pieces is important, but I think there are better ways to do it than trying to understand the unix build tools right off the bat.
FWIW, my first exposure to all of this was in high school where we were taught Turbo Pascal on DOS. It was essentially a text-based IDE, but the teacher still taught us about the editor, the compiler, the linker, etc. and it made perfect sense. When I went to use the unix tools in college, it was quite confusing.
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 th…
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.
- 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.
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 th…
Does anyone have advice for learning this kind of "intuitive, heuristic, holistic way of grokking circuits"?
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.
I read Agans's Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems back when I was in high school and still pretty new to programming. I learned a lot from it, and still recommend it. When I was in college the administrators were redesigning the CS curriculum (and are probably still fiddling with it). One of the newer classes they had come up with was a mandatory lab…
Debugging a more complex system has to do with the system in question. Sure you can teach people to set breakpoints and to run the debugger, but that's about it. Learning how to observe what is going on in any particular system is something that you learn how to do by banging your head against that system for a long time.
Earlier quoted context omitted.
> The problem is that weed out classes substitute the easier task of deciding who is prepared for the harder task of preparing students. I don't think this is the intent, at least in some disciplines. For example, I minored in math and went through the weedout class. It wasn't intentionally difficult (for some it wasn't even difficult). It weeded people out because it was the first class where you actually learn what…
The difference is that in the math class, what sent people away was not a lack of success but a lack of interest. The people who remained at least found the idea of performing proofs better than a sharp stick in the eyey. In the author's class a person could be interested and passionate about coding and not succeed and a person who felt that a few hours solving a homework was a lot of time spent coding could.
Earlier quoted context omitted.
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 :)