←back to thread

I should have loved electrical engineering

(blog.tdhttt.com)
157 points tdhttt | 2 comments | 01 Sep 25 09:12 UTC | HN request time: 0s | source
Show context
pclmulqdq ◴[04 Sep 25 10:58 UTC] No.45125831[source]▶
EE encompasses a lot of "engineering that takes hard math" at a professional and research level (similar to "hard CS," just different fields of math), so it is very hard to do as an undergrad, when your background in complex analysis and E&M is weak.

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.

replies(7): >>45126229 #>>45126357 #>>45126514 #>>45127402 #>>45127675 #>>45128168 #>>45128950 #
dfawcus ◴[04 Sep 25 14:03 UTC] No.45127402[source]▶
Yeah - there was a massive filtering of the students between the 1st year entry, and the second year at my Uni. Largely down to people unable to handle the (not terribly) complex maths at that stage.

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.

replies(2): >>45128577 #>>45131315 #
Eggpants ◴[04 Sep 25 15:46 UTC] No.45128577[source]▶
I went into EE wanting to learn how to design CPU’s and thought the analog side would be boring.

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.

replies(4): >>45128876 #>>45129325 #>>45129968 #>>45133267 #
choilive ◴[04 Sep 25 16:51 UTC] No.45129325[source]▶
Control theory was also one of my favorite classes that a low of software people should learn (at least the very basics). So many hand rolled heuristically driven if/else type systems that can simply be replaced more reliably with a PID.
replies(2): >>45132020 #>>45132403 #
Karrot_Kream ◴[04 Sep 25 20:46 UTC] No.45132020[source]▶
I've played around with this over the years in my career but have found that tuning PID loops is very tricky, much trickier than creating a soup of if/else clauses and much less auditable to those who don't understand the math.
replies(2): >>45132591 #>>45133301 #
1. dreamcompiler ◴[04 Sep 25 23:14 UTC] No.45133301{3}[source]▶
Yes, but...

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.

replies(1): >>45133698 #
2. Karrot_Kream ◴[05 Sep 25 00:15 UTC] No.45133698[source]▶
Maybe I should add more context. I have specifically tried applying PID style feedback systems to computational problems, not controllers that interface with hardware, circuits, etc. My undergrad was in math and electrical engineering, I "pivoted" to software as a grad student (though I was always very involved in the software side of my department; I was a coder from when I was a kid.) The place I found it to work the best is with designing a homegrown autoscaler years before k8s ever became a viable thing for a company to play with [1]. Most of the problem domains I applied it to do not have linear models that can effectively model the theory. Yes I know that a PID is only proven to be stable when working with linear systems, but this is the reality of the problems I've worked with.

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.