I should have loved electrical engineering

Early classes on circuits in EE will usually take shortcuts using known circuit structures and simplified models. The abstraction underneath the field of analog circuits is extremely leaky, so you often learn to ignore it unless you absolutely need to pay attention.

Hobbyist and undergrad projects thus usually consist of cargo culting combinations of simple circuit building blocks connected to a microcontroller of some kind. A lot of research (not in EE) needs this kind of work, but it's not necessarily glamorous. This is the same as pulling software libraries off the shelf to do software work ("showing my advisor docker"), but the software work gets more credit in modern academia because the skills are rarer and the building blocks are newer.

Plenty of cutting-edge science needs hobbyist-level EE, it's just not work in EE. Actual CS research is largely the same as EE research: very, very heavy on math and very difficult to do without studying a lot. If you compare hard EE research to basic software engineering, it makes sense that you think there's a "wall," but you're ignoring the easy EE and the hard CS.

Fabs are specific to the manufacturing of integrated circuits.

EE encompasses more than just manufacturing of ICs, for example research and applications in radio propagation and EM/wireless, signal integrity, antenna design, coexistence/desense, advanced power electronics, control systems, simulation/solvers, etc.

Might just be me, but I found it all clicked when we started learning the fundamentals underneath these abstractions. For me it was harder in the first classes because it's about memorizing poorly understood concepts, my brain prefers logically deriving complex concepts as a learning method.

I say all this as a recovering semiconductor engineer: EE is a huge field. I can’t think of a subdiscipline where we’ve run out of new ideas to explore, and most of them don’t require bucketfuls of HF. The real problem is that the financial rewards are relatively small, the math is ferocious, and there are so few practitioners, let alone experts doing research.

You can do a lot of actual original work without a fab.

The gaps between the analogy and the real world actually make it harder to understand the fundamentals and just confuse people when you get to a deeper level understanding. It requires more unlearning than is worth it for the slight benefit of making the concepts slightly more intuitive to understand at the beginning.

Electricity behaves in many ways just like water (just at a significantly faster time scale) but I don't think it actually helped me learn how it all worked to start with.

1. Learn soldering

2. Treat circuits like black boxes. If I need X amount of Y, e.g. I need a circuit to smooth the voltage, I pick one black box with adequate attributes.

However this is pretty introductory and I have no idea how to learn to fix old consoles. Sometimes it’s just a broken capacitor but I first need to figure out which part is broken.

Agree that complex EE work can be expensive for individual and smaller companies, indeed :)

A comment on the application side:

> "[..] for wireless applications you can follow the recommendations of the IC vendor and the remainder of the work is RF-engineering"

Zoom out to the system level, and you cannot just rely on IC vendor recommendations, and this kind of engineering can still require access to $$ labs.

Similar to complex software systems: for example take a large scale distributed system made out of many individual frameworks and services. The system as a whole may now exhibit emergent behaviour, and have failure modes due to the complexity of the system.

Same happens in complex EE designs, your design might pack in multiple cutting edge RF radios such as mmWave, UWB, with bespoke power amplifier, detection and antenna designs. Add in EM from multiple clock domains, high power distribution circuits, digital noise from FPGAs/CPUs, and EM from nearby sources. You can easily have noise couple from sources causing unintended issues in other subsystems. The vendor may say "keep a way from sources of noise", but your application may still be to engineer a solution that fits in the design envelope of a modern smartphone. The system level design needs to be engineered for EMC and coexist/desense, and validated which takes a ton of lab simulation and measurement/characterization work.

https://youtu.be/2AXv49dDQJw?feature=shared&t=1248

Which is why I also don't generally like analogies and the kind

I knew a number of folks in the first year who were very good at practical electronics, having come in from a technician side, but simply gave up due to the heavy maths load.

It got more complex when doing Control Theory, what with Laplace and Z transforms, freq domain analysis, and the apocryphal Poles and Zeros.

Further culling ensued at that point.

I think the explosion in availability of inexpensive microcontrollers and FPGA dev boards have made it much easier for people to get into hardware design without spending a ton of money. This has also made it cheaper to buy high end test equipment, you don't need to buy a $3k Keysight oscope when a cheap Chinese USB oscope works just as well with plenty of features built-in for free. Obviously a proper academic or corporate research lab is going to be a lot different than a well-equiped hobbyist lab but the difference is not as stark as you'd imagine.

But aren't there a lot of actual hardware products that are "simple circuit blocks connected to a microcontroller"? Like a toaster, shaver, keyboard, etc. If that's not "work in EE" then what is it classified under? It's not CS either.

In EE the factories that produce PCBs are also called fabs.

At most levels, software will be in there somewhere, even those fake flickering candle LEDs have RAM, ROM, and a processor these days.

The Perseus Cluster of galaxies is estimated[0] at something like 816,592 light years in diameter, so that's 10^21 meters, and on the other end 2008 TC3[1] is an asteroid 4.1m across.

[0] https://www.universeguide.com/galaxy/perseuscluster

[1] https://thesolarsystem.fandom.com/wiki/2008_TC3

However, control theory turned out to be my favorite class. Learning how negative feedback loops are everywhere was an eye opener.

Also learning Laplace transforms was one of my first “holy shit this is freaking clever and cool” moments. Just like how parity bits in data streams can be used to detect AND correct errors.

Most of the orgs I worked in building simple circuit blocks connected to a microcontroller either farmed out the actual EE work to contractors or design houses or had 1 EE for like 20 different projects.

a) inspect for obviously damaged components. Capacitors that leaked, chips that released the magic smoke, etc.

b) confirm voltages are good

c) inspect the inputs and outputs of the ics to see if they're doing what you expect

d) depending on the boards involved, a lot of checking if pin A is electrically connected to pin B when it should be. Sometimes traces get broken and need to be fixed up.

If you start with easy circuit models, at least the labs can put together something tangible in the first couple semesters, to keep people interested.

And, I mean, a lot of engineering students end up going into sort of technician-y jobs, so keeping the hands-on spark alive has a lot of value, IMO.

I wonder, how much control theory is there in CPU?

And if you managed to move ahead in hard mode, you shouldn't feel insulted.

That is largely true of academic research. A critical difference though is that you don't need big expensive hardware, or the like to follow along with large portions of the cutting edge CS research. There are some exceptions like cutting edge AI training work super expensive equipment or large cloud expenditures, but tons of other cutting edge CS research can run even on a fairly low-end laptop just fine.

It is also true that plenty of software innovation is not even tied to CS style academic research. Experimenting with what sort of perf becomes possible via implementing a new kernel feature, can be very important research but isn't always super closely tied to academic CS research.

Even the more hobbyist level cutting edge research for EE will have more costs, simply because components and PCBs are not exactly free, and you cannot just keep using the same boards for every project for several years like you can with a PC.

Is it an analogy or are both models expressions of some underlying model of potentials and flows, and we happen to have more hands-on experience with water?

I was working as an SW Engr and taking a set of courses towards a Mechatronics certificate (my employer did a lot of motion control work) and I had to basically take updated versions of the same classes. The lab instructor was an about-to-retire engineer from Schunk, and he did an amazing job of explaining what the theory meant in terms of real-world behavior. That's when it all finally sunk in and I could look at the math and "see" how a mechanism would respond.

Another commenter pointed this out, but those products take about 1-2 days of engineering time.

There might be a structural issue if you have a bunch of guys coming in from the technician side, as you say, who almost all get filtered out. You might need remedial classes, a different curriculum progression, something. Or else recruitment standards/expectation-setting are wacked-out.

I just think this gives much better results. The model can be as simple or complex as you need, and we aren’t trapped in the linear response range. PID is good enough for many tasks, but it’s never good.

One minor caveat is that most CPUs nowadays contain phase-locked loop (PLL) clock multipliers. Those fall into the domain of control theory but strictly speaking they're not part of the logic.

If you can model your problem with linear differential equations then control theory replaces the need for tuning. The coefficients you need just pop directly out of the analysis.

Eventually when if statements stop working I found that decision trees work great and XGBoost continues to be a great iteration of a decision tree.

[1]: I was an early hire at a tech unicorn and we built an autoscaler pretty early into the company's tenure. While it was a great success for a long time once k8s became established in the industry we had a really hard time training new talent to it and I left as we began a massive company-wide effort to move our workloads onto k8s.

Voltage drops across components or look a like head drops across pipe fittings. Losses along a pipe are similar to wires. Head and flow rate are very similar to voltage and current across multiple paths. Kirchoff can apply to both etc.

Many of the quantities have direct parallels and derive from each other in similar ways.

Obviously there are limits. But my middling DC circuit knowledge helped a lot when learning hydraulics from a mathematical engineering perspective.

To me EE = heavy math and that’s what makes it so fun.

I actually do software now but it’s completely different. There’s like no math in most applications of it. Putting something together with a Rasp Pi or Arduino feels like 98% software and 2% EE.

Assume beginner knowledge of relevant mathematics/electronics and good software skills.

Am interested in both the practical side (eg. build a SDR from components) and the theoretical side i.e. the Physics/Mathematics to explain it.

It should be pretty obvious that you cannot overcome constraints by moving even harder in the direction of the constraint, which is what the integral term does.

I think it would have helped me if we talked about the motor or other examples first, and then did some math to show how the resonant behavior can be useful.

I maybe had the most trouble just figuring out which instantiated PLL in the chip belonged to which PLL design, and where someone stuck the documentation in the giant repo. Especially since a hardware designer may think, oh we don’t need to update the docs, “nothing changed,” but the PLLs did change names because of a process change and their parameters may have changed slightly, even if they’re essentially the same. And chasing down small changes and documenting them ends up being a lot of the job in software.