I should have loved electrical engineering(blog.tdhttt.com)
blog.tdhttt.com
I should have loved electrical engineering
https://blog.tdhttt.com/post/love-ee/
137 comments
>Early classes on circuits in EE will usually take shortcuts using known circuit structures and simplified models.
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.
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.
My biggest criticism of EE pedagogy is that it tends to proceed from abstractions and then derive the whole world. This makes it a bit of a slog for a lot of students. I’d like to see an application-first approach that builds up principles from observed behavior. Like, measure the slip in an induction motor and then work out what’s going on there, instead of deriving motors from Maxwell’s equations.
That's a good point, too, I had a bunch of abstractions without applications in my head.
Its interestine, when you say abstractions. Could you explain what you mean by abstractions in this context and what do you mean by the underlying fundamentals.
One example would be resonant circuits. Ok great you can build resonant circuits, but what for? The fundamentals to understand frequency responses came later in signals and systems. The application came much later when I learned about electric motors, which basically behave like low pass filters (resonant circuits) which enables us to use PWM to generate sine shaped current curves by switching the input voltage on and off. The voltage signal is smoothed by the LPF circuit that is the motors windings.
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 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.
It’s crazy that VFDs work! You have to have a really good ground though, or you get arcing through the bearings.
There isn't enough time. A leisurely exploration from observations is what you do on your own time. School has a certain amount of material to convey in a certain time. That means learn the axioms and rules as best you can and get to work paying off that enormous student loan.
Massive waste of time. So much happens in a way that is not intuitive nor easily observable that starting from the math is much better.
The blog post describes the problem with this strategy, I think—the author was already pulled over to the CS side because they could just throw together a web app that people could actually interact with, day one.
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.
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.
So set your sights lower? A lot of BS EEs exit the process understanding neither Maxwell’s equations nor which end of a soldering iron to hold. The degree demonstrates that they are good at abstract symbol manipulation, and that’s not nothing, but it’s not very intellectually fulfilling and it filters out a lot of people who could be good engineers.
I remember having two class about networking, the first one was top down, it was awful, the second one was bottom up, everything clicked.
Why is bottom up or top down needed? Why can't you just explain everything at a high level first and then get into the details?
Teaching solutions without even mentioning the problems, basically. I hate it.
Don't forget, Faraday hated math.
Yeah, this kind of idea is why I’m dead against using things like the hydraulic analogy in early EE for anyone who is ever going to want to do more than the ‘hook some things up to an Arduino’ (or probably ESP32 these days) kind of level electronics.
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.
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.
Once I ditched the hydraulic analogy and really tried to internalize charge, current, voltage, etc. is when I finally started to understand why the hydraulic analogy "works" but only for people who already understand electricity.
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.
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.
This is a common problem in all fields IMO. It's easy for many to fall into the "It's like X" but it only makes sense if you already have the information needed in your head to connect the dots
Which is why I also don't generally like analogies and the kind
Which is why I also don't generally like analogies and the kind
This reminds me a lot of the car analogy that gets used to (poorly) teach object oriented programming.
Hum... The hydraulic analogy is for school kids to learn what electricity is. If you are creating circuits to hook into an arduino, you should have moved from it already.
I feel insulted.
Instead, if you still use it, just drop it because it's probably holding you back.
And if you managed to move ahead in hard mode, you shouldn't feel insulted.
And if you managed to move ahead in hard mode, you shouldn't feel insulted.
I believe school kids should be already creating circuits and hooking them up to arduinos.
It is a flawed analogy but it behaves like a fluid more than most realize:
https://youtu.be/2AXv49dDQJw?feature=shared&t=1248
https://youtu.be/2AXv49dDQJw?feature=shared&t=1248
Electricity behaves a lot like a fluid. But not much like water or air, so there's little point in using it as an intuitive analogy.
I had a CS professor as an undergrad who would teach a couple of advanced seminars in his own research area. His approach to those simplifications was to announce, "I'm going to lie to you now, but just go with it and I promise that later we're going to learn the real truth." I liked that as a compromise, to make some practical progress, but not to mistake the simplification for full understanding. (And he wasn't rigid about it -- if somebody would ask a deeper question he'd happily answer it to some level and then get on with his plan.)
The hydraulic analogy always sort of confused me because, like, fluid mechanics are real complicated. So, I always had this gut feeling question of like, can we actually end up with a hydraulic analogy that is exactly as complicated and electricity and magnetism? If we push the analogy beyond what is intended?
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?
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?
Yeah. As I mentioned in another comment, as someone who studied Civil Engineering (ages ago) maybe most EEs never learn enough hydraulics to know the analogy probably goes further than they realize - ie much further than just kids level stuff.
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.
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.
Heh, I used electrical circuit analogies when learning hydraulics for pipe networks in Civil Engineering. I struggled much less than the other students who didn't know any basic electrical stuff from physics classes.
This is especially true because for doing most _hard_ EE work, you really need access to a fab, and so a lot of money. This is not really the case for most hard CS work.
By fab you mean lab, then agree.
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.
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.
This is true, although for wireless applications you can follow the recommendations of the IC vendor and the remainder of the work is RF-engineering, not research. That's why I said fab, not lab. But yes, you are right to a great extent. The main point is that the hard EE work can be prohibitively expensive for individuals and smaller companies.
I think you're oversimplifying this. Lots of RF research is done with a DAC, an ADC, an FPGA, and a frontend made of discretes (sometimes also with off-the-shelf boxes connected with SMA connectors). A lot of power electronics research is done with microcontrollers and discrete parts. Digital circuits research often stops on an FPGA or in a simulator.
You can do a lot of actual original work without a fab.
You can do a lot of actual original work without a fab.
Can you recommend some good resources (books/videos/etc.) for studying RF Engineering and doing RF Research by oneself?
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.
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.
Sibling poster did a good job explaining how research relies on labs.
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.
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.
> Fabs are specific to the manufacturing of integrated circuits.
In EE the factories that produce PCBs are also called fabs.
In EE the factories that produce PCBs are also called fabs.
Fabs are only part of this, and not universal in EE research at all. However, almost all serious EE research requires at least $100k of lab equipment of one kind or another.
That's definitely an unfortunate part of EE, the hardware required to design hardware is expensive. CS requires a laptop and maybe some time on a server or a big GPU cluster, expensive to own but very cheap to rent.
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.
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.
“Things you can only do in a fab” is but a subset of “hard problems in EE.” How many people actually understand induction motors well enough to design a better one? Or how about antenna theory? The math makes most people’s eyeballs melt, and the space of possible antenna designs is utterly unfathomably huge. And then there’s acoustics, which is just like antenna theory except the math is sideways. I could go on. Control theory. Analog signal processing. Digital signal processing. Biomedical.
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.
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.
Does radar or radar reflection not count as "hard"? There's a lot more to electronics and electrical engineering than ICs.
Interesting. My approach to hobbyist EE (actually embedded) is:
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.
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.
Fixing old consoles is roughly...
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.
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.
Fixing consoles is also treating circuits like black boxes :) . just gotta know what the black boxes are
Circuits as black boxes is usually a very leaky abstraction, because how circuits work depends a lot on what’s connected to them. And they have plenty of attributes that can interact in very weird ways.
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.
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 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.
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.
Same on the laplace transforms. I was kinda mad we had learned any other way. It was a lot easier than whatever we were doing before mathematically!
I wonder, how much control theory is there in CPU?
I wonder, how much control theory is there in CPU?
In computer architecture / digital ASIC design there's zero control theory. There's not much mathematics in general.
There's Boolean algebra but no control theory is needed for logic design.
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.
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.
And in my inexpert experience, they are IP developed by the fab. So if you are doing CPU design work, you may need to understand PLLs well enough to read a datasheet, but you will not need to design a PLL.
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.
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.
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.
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.
PID is standard in the industry, but the reality is it is infinitely easier to model in the discrete domain. The z-plane if math, but you don’t really need much math. Just model like a games developer. Simulate with a bit of JS or python. Add the motor saturation! Play with feedback and disturbances.
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.
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.
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.
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.
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.
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.
Absolutely the worst control systems of all time have been written by software engineers that don’t understand control theory. The second worst control systems are designed by those who only know the PID heuristic, and can’t be bothered to model a little non-linearity from motor drives saturating.
The biggest problem with PID control is that the integral term performs double duty as both a signal that accumulates small errors to minimize the steady state error, but also as a signal that shows deviation from the target due to unmodeled constraints.
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.
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 never really "got" control theory until about 10 years after graduation.
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.
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.
Agreed on the Laplace transforms. They instantly turn linear differential equations into basic high school algebra problems. But they don't work for nonlinear problems.
I remember when I first learned calculus and holy shit that was cool already. Then it kept getting better and better as I learned differential equations, linear algebra, etc.
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.
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.
I sometimes wonder if math suffers from a bit of basketball syndrome. That is, I'm sure there are dozens of potential Muggsy Bogues-esque players out there, but the game's meta continues to drift ever towards who coaches and trainers know how to coach and train, which is tall dudes.
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.
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.
> Plenty of cutting-edge science needs hobbyist-level EE, it's just not work in EE
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.
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.
Computer engineering is the degree for that.
That would be Computer Engineering. Its somewhere between EE and CS.
The actual electrical engineering involved there is the sort of thing that an early-career engineer could bang out in an afternoon. Maybe a day or so for the PCB designer. The more time consuming part might be managing the regulatory compliance testing.
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.
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.
It would have been better phrased as "research in EE." There's no research involved in building a toaster.
Another commenter pointed this out, but those products take about 1-2 days of engineering time.
Another commenter pointed this out, but those products take about 1-2 days of engineering time.
I'm sure part of it is that EE claims probably the widest range out there. You can have kilovolts or microvolts, but mostly the same rules apply. Or you can learn how to power a small sensor for years off one small battery, or how to power a country. I don't know many other disciplines that can lay claim to 10-15 orders of magnitude.
At most levels, software will be in there somewhere, even those fake flickering candle LEDs have RAM, ROM, and a processor these days.
At most levels, software will be in there somewhere, even those fake flickering candle LEDs have RAM, ROM, and a processor these days.
I feel like astronomy probably wins, the magnitudes are literally astronomical.
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
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
> Actual CS research is largely the same as EE research: very, very heavy on math and very difficult to do without studying a lot.
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.
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.
When I studied electrical engineering, I'd say that a good half of our class were your typical "DIY" tinkering guys, which had been a hobby for quite some time. For some, like me, it was audio equipment. Guitar amplifiers, effects pedals, and all that. For others it was robotics. Other again enjoyed building their own DIY home automation systems. Or fitting mechanical systems with sensors and such, ham radio, whatever.
But, yes, probably half of my classes were a real drag to get through. It all depended on who the lecturer was, and how enthusiastic they were.
But, yes, probably half of my classes were a real drag to get through. It all depended on who the lecturer was, and how enthusiastic they were.
Funny. I studied EE in 2012, and by that time, according to professors, there weren't many hardware tinkerers in the group compared to the 1990's. Many more people saw it was a good field that's comparable to CS. At this time, EE was on the way down and CS was on the rise in popularity. The classes were absolutely brutal for most people because they came in with less of an understanding of it.
I think the drop in tinkering is due to the high skill/cost barrier to entry particularly SMT, and lab equipment. If you want to do anything interesting beyond a breadboard and arduino/rpi you are going to need to invest in a custom pcb and lab equipment. With SMT, I got into EE/HW by taking things apart and studying them, back then (late 90's) most consumer stuff still had a good mix of thru-hole and SMT so tinkering was easy. Now almost nothing is thru-hole so if you want to fix or modify anything you are going to need more than a cheap harbor freight soldering iron.
I duuno, a custom pcb costs a dollar and you solder it with a cheap hot plate instead of an iron
repair is definitely not the gateway it used to be, though
repair is definitely not the gateway it used to be, though
I disagree. It has never been cheaper to get decent equipment.
Custom PCBs have been $5/square inch for a set of 3 from OSHPark for many years.
You can buy a usable hot air station on Amazon for the price of a DoorDash meal.
Custom PCBs have been $5/square inch for a set of 3 from OSHPark for many years.
You can buy a usable hot air station on Amazon for the price of a DoorDash meal.
Do you have a recommended hot air station for tinkerer use? I am trying to move up from breadboarding into something more field-deployable proof of concept.
Look up '959D' as a model. They're serviceable hot air stations made by a bunch of different white label vendors that are usually $40-60 on the likes of Amazon, cheaper elsewhere.
You can work with SMT at home no problem. A decent hot air station like Quick 861dw will cost you just about $300 and you don’t need much more to tinker.
I love this perspective. I wanted to be Tom Scholz from Boston (though he was an ME, and that was my dad’s music).
My junior project in EE was a guitar fx pedal with a shielded breadboard on top. I won’t be bashful, that was the most popular project in the room.
Then… I got divorced and never finished my EE degree. I already had a degree in CS, and had pursued a second degree because I thought software was too limiting. Now, here I am, all limited.
The reason I never subsequently finished my degree was that I didn’t really want to work on CMOS nor transmission lines or microwave, and graduating with an ECE degree from U of Utah offered those as your career paths.
My junior project in EE was a guitar fx pedal with a shielded breadboard on top. I won’t be bashful, that was the most popular project in the room.
Then… I got divorced and never finished my EE degree. I already had a degree in CS, and had pursued a second degree because I thought software was too limiting. Now, here I am, all limited.
The reason I never subsequently finished my degree was that I didn’t really want to work on CMOS nor transmission lines or microwave, and graduating with an ECE degree from U of Utah offered those as your career paths.
If you want to learn how to solve problems with hammers, engineering is what you want to do. If you want to know how the hammer works, do mathematics or physics. If you want to get paid, do software.
This is why I did an EE degree, didn't get paid much, went into software and used that to pay for a mathematics degree.
This is why I did an EE degree, didn't get paid much, went into software and used that to pay for a mathematics degree.
This is outdated advice. If you want to get paid, get a hammer.
I disagree with this entirely as I rather like a desk job and hammers make my hands hurt after a bit :)
If you want to get paid in software don't do something utterly commoditised and popular or you're just a fungible meat flavoured work unit. Get really damn good at something with some longevity in a stable niche.
If you want to get paid in software don't do something utterly commoditised and popular or you're just a fungible meat flavoured work unit. Get really damn good at something with some longevity in a stable niche.
Not just a niche but something requiring domain experience. If your resume says “will React for food”, you are competing with a million other people. If your resume also says you understand a particular industry, user community, etc. you stand out of the generic community.
And once you're actually using that hammer for real work, you'll learn how to use it to solve all sorts of problems, better than any school could teach you.
Here's a screw, here's a bit of wood. What tool do you use...? ;)
Screws are incredibly difficult to hammer in. Use a big hammer.
Develop an AI model that can generate an image of a hammer riding a bycicle.
And then fleece some VC investors and disappear before they notice you're losing money!
Get a website that just sells hammers. I'm sure it already exists.
Quick search. Yup, it exists. "The Hammer Source: 100's of Hammers"
Reminds me of Hank Hill "I sell hammers and hammer accessories."
Reminds me of Hank Hill "I sell hammers and hammer accessories."
I don't think engineering gets paid well compared to software. And by engineering I mean any physical forms of engineering that doesn't fall into "software engineering". The advice seems pretty accurate to me.
In that analogy it also works that in that the level of cognitive difficulty is most challenging @ physics theoretical work --> engineering --> software. Inversely proportional to pay check size. Though a physicist can probably figure out software whereas the other way is a tougher slog.
In that analogy it also works that in that the level of cognitive difficulty is most challenging @ physics theoretical work --> engineering --> software. Inversely proportional to pay check size. Though a physicist can probably figure out software whereas the other way is a tougher slog.
> It seemed crazy to me that with all the amazing technological advancement we had, our efficiency in communicating via the computer wasn’t much higher than someone with a typewriter 150 years ago.
We're making electric super cars that still use a steering wheel and gas pedal. Just because it's old doesn't mean it's deficient. Humans haven't fundamentally changed in the past 100 years, so it is probably the most intuitive way to manually control a car.
The typewriter/keyboard is probably the most intuitive method to input alphabet characters. Of course that doesn't preclude entirely new ways to control our computers. But if you set out to simply replace the mouse and keyboard without fundamentally changing how we interact with a computer, then you're setting yourself up for failure.
We're making electric super cars that still use a steering wheel and gas pedal. Just because it's old doesn't mean it's deficient. Humans haven't fundamentally changed in the past 100 years, so it is probably the most intuitive way to manually control a car.
The typewriter/keyboard is probably the most intuitive method to input alphabet characters. Of course that doesn't preclude entirely new ways to control our computers. But if you set out to simply replace the mouse and keyboard without fundamentally changing how we interact with a computer, then you're setting yourself up for failure.
Weirdly my background is physics and CS and I am recently discovering a love of EE. I don't think it's as easy to pare these subjects apart as history suggests. Modern bleeding-edge solutions require a "full-stack" understanding. If you know maxwell's equations with your physics knowledge - then you can implement them numerically with your CS knowledge - build a hardware optimized version with verilog/FPGA with your EE knowledge.
The EE component of my CSE degree felt like a math degree in disguise. Calculus, linear algebra, differential equations, discrete mathematics... It was a long time ago but I remember it as three years of math prerequisites and Maxwell’s equations and then finally we could learn what a MOSFET is. Absolutely terrible. I just want to learn how circuits work and how to build a guitar amp! But noooooo I need to learn how to solve partial differential equations, which I’ve done zero times in the field.
100% this
And then circuit analysis is just a big exercise in building "castles in the sky" and worrying your upside down staircase has railings
(Among other several pet peeves about EE that I could go on about)
And then circuit analysis is just a big exercise in building "castles in the sky" and worrying your upside down staircase has railings
(Among other several pet peeves about EE that I could go on about)
I agree that is excessive. But I would hate equally, if not more, learning with magic rules delivered by the professor in the sky. The info doesn't stick for me unless I understand the intuition behind the reasoning.
Yeah I had a magic-rules-first style experience in my EE program and it really didn't work for me at all. The nebulous reasoning made it for me where I just really couldn't internalize the pretty basic "rules" because I couldn't help but mess myself up overthinking the more abstract modes of conceptualizing everything which just confused me more. I'm thankful because it gave me the opportunity to quickly learn that I was a lot better at code than circuits, I probably would've been screwed if it took me that long to get to that point in my educations, but I will say the magic rules just did not work for me personally as a way to understand things. I'm sure others would do a lot better at just jumping right in though.
I also just wanted to build a guitar amp.
I worked with EE for a while and it was very boring building stuff.
It basically took me changing careers to SWE and working for a games company to finally use the math part of my EE degree.
I ended up building my guitar amp years after.
I worked with EE for a while and it was very boring building stuff.
It basically took me changing careers to SWE and working for a games company to finally use the math part of my EE degree.
I ended up building my guitar amp years after.
There are people who think engineering is basically Lego but bigger, and people who think engineering is applied physics.
They're different jobs.
The Lego level is more like being a technician. You can slap a few ready-made building blocks together, maybe tweak them a little using basic algebra, and you've got your design.
That's fine for guitar amps and simple synth circuits and such.
But if you use that approach while designing the control circuitry for a power plant or a rocket motor, in the best case failure will be very expensive, worst case people will die.
That's where the real engineering happens. You're modelling systems from first principles and you know enough to be fairly confident that the equations you create to characterise a complex design with multiple inputs and outputs accurately predict its behaviour.
If you start with hobby electronics you have zero experience or insight into that level. So when you begin your course you're completely blindsided by how much math there is, and have no idea what it's for.
And some domains, like robotics, have even more math. You can use plain old EE control theory, but you can extend it into modelling systems using Lie groups and Lie algebras - which are more often used in quantum physics.
They're different jobs.
The Lego level is more like being a technician. You can slap a few ready-made building blocks together, maybe tweak them a little using basic algebra, and you've got your design.
That's fine for guitar amps and simple synth circuits and such.
But if you use that approach while designing the control circuitry for a power plant or a rocket motor, in the best case failure will be very expensive, worst case people will die.
That's where the real engineering happens. You're modelling systems from first principles and you know enough to be fairly confident that the equations you create to characterise a complex design with multiple inputs and outputs accurately predict its behaviour.
If you start with hobby electronics you have zero experience or insight into that level. So when you begin your course you're completely blindsided by how much math there is, and have no idea what it's for.
And some domains, like robotics, have even more math. You can use plain old EE control theory, but you can extend it into modelling systems using Lie groups and Lie algebras - which are more often used in quantum physics.
>If you start with hobby electronics you have zero experience or insight into that level.
Sounds like if you start with the math before you're old enough to pick up a soldering iron it might be a little different.
Sounds like if you start with the math before you're old enough to pick up a soldering iron it might be a little different.
You could do engineering without knowing about partial differential equations, or numerical methods. Most digital IC designers, FOGA guys etc do that. You would be missing some tools though. Not needing a tool ever doesn't mean it's not used anywhere else. You can't get into RF, proper signal integrity, or analog circuits without these and some more.
Community college is the short cut. My local AAS EET program went safety -> DC -> AC -> amplifiers in 4 semesters.
More people should get into EE and see it all the way through. And, rather than getting a masters degree or PhD, go straight into industry. Why? Because just beyond what you learn in your BSEE degree lies one of the most fascinating topics ever: Signal integrity.
I understand why a lot of people bail out of EE, and why a lot go to web dev specifically. EE relies so heavily on simple calculus that there's a distinct moment where you have to go "what the heck am I actually learning?". And seeing that software has this apparent depth (design patterns, OOP principles, Haskell, ORMs, Fieldingian REST, GraphQL, 10,000-word blog posts on vim vs emacs, etc.), they naturally get drawn there.
I understand why a lot of people bail out of EE, and why a lot go to web dev specifically. EE relies so heavily on simple calculus that there's a distinct moment where you have to go "what the heck am I actually learning?". And seeing that software has this apparent depth (design patterns, OOP principles, Haskell, ORMs, Fieldingian REST, GraphQL, 10,000-word blog posts on vim vs emacs, etc.), they naturally get drawn there.
I am currently on the EE path but the CSEE side is very tempting. Right now the "information/computer engineering" seems much more popular than "plain" EE. I wouldn't study pure software because it doesn't seem connected enough to the real world (...or I am coping for my weak algorithmic thinking skills).
Maybe one day I will actually understand signal integrity but so far my experience has been "check return paths, match impedances and pray to the EE gods".
Maybe one day I will actually understand signal integrity but so far my experience has been "check return paths, match impedances and pray to the EE gods".
You exactly describe my journey! After undergrad, I went right to industry doing hardware design. Given a complex PCB, I was confronted with this field of signal integrity and I fell in love with it. My undergrad didn't explicitly require EM courses, but I learned on the job (lots of reading plus guidance from some experienced RF engineers). Eventually I went back for my master's, and it was so nice knowing exactly which niche I wanted to focus on (and finally get a ton of EM fundamentals under my belt). It truly feels like EE is an infinite field with no limit to the possible type of work...
TL;DR author discovers there is little overlap between EE and CS.
Hardware and software are called different things for a reason? I do agree that tinkering with the hardware always needs to be in-step with the lesson at hand. You can't just state KVL/KCL and move-on, you need to have the student build a circuit and play with it for a day or two.
Hardware and software are called different things for a reason? I do agree that tinkering with the hardware always needs to be in-step with the lesson at hand. You can't just state KVL/KCL and move-on, you need to have the student build a circuit and play with it for a day or two.
The build part was really helpful for me when I really struggled with EE. My program only ever made us build things for very first semester "build a circuit to light up the LED" type labs. Once we got to even the most basic of components it all became on paper. I really struggled with some of the mental models to the point where I made a habit of going out of my way to build a lot of circuits that I was just supposed to solve on paper. Getting everything correct felt no different to getting things completely wrong in a paper problem until I actually built out the circuits and suddenly "correctness" actually became a real thing that I was tangibly experiencing. I wish my program would've at least taught SPICE a little more to at least scratch the ability to simulate things a little better.
In all of my EE or computer hardware classes at uni, we had weekly labs that required hands on building circuits. Often the labs were the most challenging part of the class. Is that not common?
I had the same experience, every EE class had a lab component even the intro ones. At my school, the labs for junior and senior classes were all scheduled 6PM to 10PM and almost all of them took that long or longer to complete.
No? There's plenty of overlap. I studied computer engineering in undergrad, which is similar to the author's original major. There are a lot of subjects that straddle the boundary, like computer architecture, embedded systems, and digital signal processing.
Obviously yes, if you're doing heavy analog/power/RF stuff you're going to be pretty far from software, but EE is a really broad field.
Obviously yes, if you're doing heavy analog/power/RF stuff you're going to be pretty far from software, but EE is a really broad field.
For me, it's a bit of the reverse. I initially wanted to go into CS, but had to start with 2 years of generic fundamentals closer to your regular EE curriculum. Ended up majoring in finance. Have been able to catch up quite nicely on my own on the CS knowledge since it's just software. But I miss the EE parts.
I can't build the remotest smallest device with my hands.
After high school I thought I would go onto studying supraconductors and stuff.. Go figure, I got lost along the way, smh.
The feeling you got when tinkering is the same I got when first studied formal electronics in HS. I didn't do college, but the only one from my graduation year who stayed into electronics until now it's me. It's been 12years and I'm still doing it. I've been blessed enough to have encountered people that paid me to do Industrial Design and Product R&D.
I'm now currently in manufacturing and automation.
I learned BASIC when I was 7 in the early 1980's. I went to a very advanced high school that had Internet access in 1991 and some Unix systems. I loved it and was fascinated by all the hardware.
I started college in EE, I absolutely loved my digital logic class. I talked to one of the lab TA's in Circuits 2 and said this wasn't as interesting as digital logic. He told me to switch to computer engineering. I looked at the courses and there were only 5 classes different. I switched that week.
I've been designing computer chips the last 30 years.
> Maybe I Am Just a Software Guy
That's the TL ; DR version of the article.
The TL ; DR version of my post is "I like programming but I find hardware far more interesting."
I started college in EE, I absolutely loved my digital logic class. I talked to one of the lab TA's in Circuits 2 and said this wasn't as interesting as digital logic. He told me to switch to computer engineering. I looked at the courses and there were only 5 classes different. I switched that week.
I've been designing computer chips the last 30 years.
> Maybe I Am Just a Software Guy
That's the TL ; DR version of the article.
The TL ; DR version of my post is "I like programming but I find hardware far more interesting."
I did a lot of CS out of passion as a child but leading up to high school I was around such uniquely skilled group of friends in the field that I felt that I should pursue EE as I felt so out-skilled as a programmer. It only took me a single year of university to realize that EE was NOT my calling. I've never had so much completely fail to instinctively "click" in my brain compared to my peers. Meanwhile I was practically teaching the CS courses to my peers. I found that computer engineering was the perfect intersection for me because it let me explore so much more hardware and low level stuff without requiring analog dark magic that for whatever reason even the simplest of principles my mind couldn't grasp. I still really wish I could have gone on to make super clean headphone amps and all that but it turns out there really are just some things you can be "naturally" good and bad at, and for me it clean code not clean circuits.
edit: +1 on the "I just started bruteforcing" part of getting frustrated with everything. It was not a good way of learning but even after switching programs I found myself preferring to just bruteforce problems I had lost hope in thinking through to completion without running into a mistake that'd require me start back over from the top when I have 200 of the same type of problem to do after. So much mental effort would be wasted trying to "get" things I just wasn't getting that I started to getting more satisfaction mentally from just managing to get the solution without doing the effort of doing it "right" (ignoring that my methods of bruteforcing would probably still take far more time and energy, it was at least something that didn't hurt me spiritually on every failure).
edit: +1 on the "I just started bruteforcing" part of getting frustrated with everything. It was not a good way of learning but even after switching programs I found myself preferring to just bruteforce problems I had lost hope in thinking through to completion without running into a mistake that'd require me start back over from the top when I have 200 of the same type of problem to do after. So much mental effort would be wasted trying to "get" things I just wasn't getting that I started to getting more satisfaction mentally from just managing to get the solution without doing the effort of doing it "right" (ignoring that my methods of bruteforcing would probably still take far more time and energy, it was at least something that didn't hurt me spiritually on every failure).
You should have loved electrical engineering, but you should also have loved software engineering. It's just that the software side of your education leap-frogged straight over the fundamentals and into hacking on cutting-edge completed systems at the very beginning, which suited your desired learning style much better.
There are plenty of "applied" electronics technician or electrician's apprenticeship programs that are more like your software education. Take an induction motor, a variable frequency drive, a few sensors, and a programmable logic controller, and hook them together according to the manufacturer's instructions, and you can be off to the races operating a pump or a conveyor on day 1. But will you understand how the insulated gate bipolar transistors and filters in that variable frequency drive turn the rectified high-voltage DC bus into three-phase AC that generates a rotating magnetic field and induces a current in the motor armature? No, you don't need to know any of that to make the pump work.
You wrote:
> I couldn’t imagine ... a toy CPU implemented in SystemVerilog being ... useful
No, it's really not, but your work on real CPUs depends on registers and combinatorial logic and ALUs and MMUs. End users can typically just download Python and treat everything behind the screen as a black box, but if you really want to call what you're doing "engineering" or a "science", then developing an understanding for what happens behind the curtains is incredibly useful. If you've implemented a toy 8-bit CPU with load, store, compare, jump, and a few basic math instructions, you can write some assembly or a toy interpreter for it and you will have an understanding of how real CPUs work that can enable you to write better code later. Add some interrupts to that CPU and build a multitasking operating system, and you'll understand parallelism better.
All of modern technology is a pyramid. At the point of that pyramid is just a single doped semiconductor with a P-N junction. We build that junction into transistors, and transistors into gates, and gates into CPUs, and on those CPUs we execute assembly, and we write low-level languages that compile into assembly, and build operating systems and syscalls with those low-level languages, and access those systems with high-level languages, and connect those computers together with networks, and write applications that operate on those networks, and at the broad base of the pyramid there are billions of people using those applications.
In 2025, no one human brain comprehends the full stack anymore, we all become our own individual bricks in a particular layer. But to do the best work at any point in the pyramid, you ought to know a bit of how it works above and below you!
There are plenty of "applied" electronics technician or electrician's apprenticeship programs that are more like your software education. Take an induction motor, a variable frequency drive, a few sensors, and a programmable logic controller, and hook them together according to the manufacturer's instructions, and you can be off to the races operating a pump or a conveyor on day 1. But will you understand how the insulated gate bipolar transistors and filters in that variable frequency drive turn the rectified high-voltage DC bus into three-phase AC that generates a rotating magnetic field and induces a current in the motor armature? No, you don't need to know any of that to make the pump work.
You wrote:
> I couldn’t imagine ... a toy CPU implemented in SystemVerilog being ... useful
No, it's really not, but your work on real CPUs depends on registers and combinatorial logic and ALUs and MMUs. End users can typically just download Python and treat everything behind the screen as a black box, but if you really want to call what you're doing "engineering" or a "science", then developing an understanding for what happens behind the curtains is incredibly useful. If you've implemented a toy 8-bit CPU with load, store, compare, jump, and a few basic math instructions, you can write some assembly or a toy interpreter for it and you will have an understanding of how real CPUs work that can enable you to write better code later. Add some interrupts to that CPU and build a multitasking operating system, and you'll understand parallelism better.
All of modern technology is a pyramid. At the point of that pyramid is just a single doped semiconductor with a P-N junction. We build that junction into transistors, and transistors into gates, and gates into CPUs, and on those CPUs we execute assembly, and we write low-level languages that compile into assembly, and build operating systems and syscalls with those low-level languages, and access those systems with high-level languages, and connect those computers together with networks, and write applications that operate on those networks, and at the broad base of the pyramid there are billions of people using those applications.
In 2025, no one human brain comprehends the full stack anymore, we all become our own individual bricks in a particular layer. But to do the best work at any point in the pyramid, you ought to know a bit of how it works above and below you!
>which suited your desired learning style much better.
It's a nice way of putting it. The blunt thing that everyone is sort of dodging here is this: I think it's less learning style, and more IQ. EE is THAT much harder.
It's a nice way of putting it. The blunt thing that everyone is sort of dodging here is this: I think it's less learning style, and more IQ. EE is THAT much harder.
It's hard to put this plainly without being insulting but I have to be blunt. EE is just 100000000000x harder to learn. The distance from theory to application for EE is especially gigantic.
Software development for the most part is extremely easy. It's one of the few "engineering" fields where you can go to a bootcamp and learn it in 6 months. You won't see this kind of thing for quantum mechanics or electrical engineering.
Also the gap between theory and application in software is miniscule. Instantaneous even. You basically learn software via application.
A lot of software engineers take pride in their jobs and in their intelligence but they don't fully understand just how easy software is. Like you guys (to be accurate: most of you guys, not all) have an easy job and you learned a easy field. EE is challenging. You don't like it because it's harder and the intellectual capacity to handle it isn't there for everyone.
There's a reason why all hardware development moved to Asia. Software is just too attractively easy and the internet boom made it lucrative. Asians took whats available while the west took what’s most fun. And now the skill gap is more evident and we can’t go back.
Software development for the most part is extremely easy. It's one of the few "engineering" fields where you can go to a bootcamp and learn it in 6 months. You won't see this kind of thing for quantum mechanics or electrical engineering.
Also the gap between theory and application in software is miniscule. Instantaneous even. You basically learn software via application.
A lot of software engineers take pride in their jobs and in their intelligence but they don't fully understand just how easy software is. Like you guys (to be accurate: most of you guys, not all) have an easy job and you learned a easy field. EE is challenging. You don't like it because it's harder and the intellectual capacity to handle it isn't there for everyone.
There's a reason why all hardware development moved to Asia. Software is just too attractively easy and the internet boom made it lucrative. Asians took whats available while the west took what’s most fun. And now the skill gap is more evident and we can’t go back.
Agreed, it’s a very hot take on this website, where everyone’s egos have been inflated to near popping, but I’ve long held that most software jobs are pretty easy.
But the cool thing about software is that it has paid so well despite its relative ease, it’s a well paying field that still secures a middle class life that’s resilient to inflation.
Once that’s gone, a whole lot of people are going to find themselves condemned to dropping an economic class or two.
But the cool thing about software is that it has paid so well despite its relative ease, it’s a well paying field that still secures a middle class life that’s resilient to inflation.
Once that’s gone, a whole lot of people are going to find themselves condemned to dropping an economic class or two.
Yep, it's insane that SWEs working on products like pinterest earn more than engineers working on major infrastructure projects. Honestly without direct government intervention I think market forces will always lead to this outcome.
When MIT ran the first massive online course, 6002x, I found out that MIT 6002x was the electronics course I had wished for back when I was in high school. The high school electronics courses I took only touched upon analysis of the simplest of circuits, and there wasn't a lot of explanation of how the different kinds of transistors (NPN, PNP, MOSFETs..) are modeled.
But oh how much workload the 6002x course was... I needed 10-15 hours per week for all the reading, problems and labs, and doing that while working full time and commuting 2 hours a day was a grueling pace to survive!
But oh how much workload the 6002x course was... I needed 10-15 hours per week for all the reading, problems and labs, and doing that while working full time and commuting 2 hours a day was a grueling pace to survive!
Here is the thing about hardware vs software.
For the same mental effort, you get orders of magnitude more "end product" from software than hardware, with greatly less overhead and greatly more flexibility.
Hardware is extremely punishing and "complexity friction" kicks in almost immediately. A multi-feature door alarm on a microcontroller is a one hour affair that a newbie could finagle. With a pure hardware implementation its a multi-day effort, plus another day of reworking the board to dial it in. And if you aren't copying a design, you likely need a degree as well.
There is also the fact that software pays much more than hardware, can be done remotely from just about anywhere, doesn't involve working in labs full of lead and solvents, and like the author noted, has a much higher "wow!" factor from people in general. Software makes you feel very powerful, hardware will humble you into the ground.
For the same mental effort, you get orders of magnitude more "end product" from software than hardware, with greatly less overhead and greatly more flexibility.
Hardware is extremely punishing and "complexity friction" kicks in almost immediately. A multi-feature door alarm on a microcontroller is a one hour affair that a newbie could finagle. With a pure hardware implementation its a multi-day effort, plus another day of reworking the board to dial it in. And if you aren't copying a design, you likely need a degree as well.
There is also the fact that software pays much more than hardware, can be done remotely from just about anywhere, doesn't involve working in labs full of lead and solvents, and like the author noted, has a much higher "wow!" factor from people in general. Software makes you feel very powerful, hardware will humble you into the ground.
I had the background for EE. Grew up around a bunch of HAMs and Motorola engineers, competed in FIRST, CS Olympiads, etc. Went to a great engineering school and then had my ass handed to me end of sophomore year. So I did the reasonable thing any 20yo would do and listened to my academic advisor. Who told me that "maybe EE, just isn't for you." Seeing the economic bottom fall out for engineers and CS graduates didn't help. So, in a state of panic I transferred to the CS program. I had to extend my graduation another year.
Career wise and financially, its worked out great. Even most of my EE friends didn't do much in EE after the first 5 years. Everyone just migrated to where the jobs were: Software development, IT, and Cybersecurity.
Career wise and financially, its worked out great. Even most of my EE friends didn't do much in EE after the first 5 years. Everyone just migrated to where the jobs were: Software development, IT, and Cybersecurity.
Let me give you guys a perspective from someone who did Electrical Engineering in Africa. There are hardly any job openings centered around electronics so the programme/curriculum is Power Engineering heavy. Most of the professors did research around this area, and there were very few who did anything in the sciences. I had the chance to pick some electives from the Computer Engineering department, but this was just during my third and final year of university. Unlike OP, I did not have an issue breezing through circuit problem sets, though they felt very repetitive, I was not bad at it, nor did I fail any classes.
I had an eye opening experience when I had my first taste of programming when I took C programming in my second year of university. What do you mean I can run a command and see instant output? Amazing! This was not the case for my electronics and power engineering lab sessions. We were using equipment that had been around since the 80s with little to no supervision. Just a bunch of routine "experiments" which I can barely remember any of. In my third year, I took Digital Computer Design (a C.E elective) and I realized I had been wasting my time learning about how the power grid in my country works. I tried my best to salvage as much as I could by picking more C.E electives, albeit not many available, did as best I could.
Everyday I wonder, how different would my life have been if I studied CS or even CE, I do not know. But, I appreciate the little this journey taught me, that you can always squeeze lemonade out of whatever lemons life gives you. I see my old EE notes now and they don't make sense to me, but I appreciate the happy chills solving circuit problem sets gave me. I work in software now, and I get that 1000x more, and that is how I know I made the right choice.
I had an eye opening experience when I had my first taste of programming when I took C programming in my second year of university. What do you mean I can run a command and see instant output? Amazing! This was not the case for my electronics and power engineering lab sessions. We were using equipment that had been around since the 80s with little to no supervision. Just a bunch of routine "experiments" which I can barely remember any of. In my third year, I took Digital Computer Design (a C.E elective) and I realized I had been wasting my time learning about how the power grid in my country works. I tried my best to salvage as much as I could by picking more C.E electives, albeit not many available, did as best I could.
Everyday I wonder, how different would my life have been if I studied CS or even CE, I do not know. But, I appreciate the little this journey taught me, that you can always squeeze lemonade out of whatever lemons life gives you. I see my old EE notes now and they don't make sense to me, but I appreciate the happy chills solving circuit problem sets gave me. I work in software now, and I get that 1000x more, and that is how I know I made the right choice.
I think this article has a much simpler explanation than a lot of the points being made in the comments: When it came down to it, the author was more excited about software than hardware.
Contrast this:
> One of the EECS professors was kind enough to offer a RC car kit to his students to program it. I decided to give it a try. Maybe the toy car wasn’t exciting or maybe I was pre-occupied with other course work during that summer, I didn’t even open the box.
With this:
> Writing web applications blew my mind. I can just write some code, click a few buttons and boom all my friends and family across the globe can just see it! This feels like magic.
Anecdotally, I saw this a lot in college. Students would start out in electrical engineering because they thought hardware was really cool, but when the time came to do the hard work they didn't have much motivation. They wanted to be a hardware engineer, but putting in the work was unappealing. Software has a wider range of job opportunities from intense FAANG-level jobs down to being the person who pokes at a company's old PHP website long enough to keep it serving pages. You can jump in and find a level that matches your motivation. With hardware, you have to clear some hurdles to begin being useful at all.
To my surprise, I think Arduino and Raspberry Pi have made this worse. I talk to a lot of people who see themselves as amateur EEs because they bought an Arduino and used some jumper wires to connect some sensors to the right pins. It's exciting. Then they lose motivation when they encounter a problem that requires doing anything more complex or custom. These people often overlap with the CS students who think the entire world of software engineering is writing CRUD apps composed of APIs connected together.
Contrast this:
> One of the EECS professors was kind enough to offer a RC car kit to his students to program it. I decided to give it a try. Maybe the toy car wasn’t exciting or maybe I was pre-occupied with other course work during that summer, I didn’t even open the box.
With this:
> Writing web applications blew my mind. I can just write some code, click a few buttons and boom all my friends and family across the globe can just see it! This feels like magic.
Anecdotally, I saw this a lot in college. Students would start out in electrical engineering because they thought hardware was really cool, but when the time came to do the hard work they didn't have much motivation. They wanted to be a hardware engineer, but putting in the work was unappealing. Software has a wider range of job opportunities from intense FAANG-level jobs down to being the person who pokes at a company's old PHP website long enough to keep it serving pages. You can jump in and find a level that matches your motivation. With hardware, you have to clear some hurdles to begin being useful at all.
To my surprise, I think Arduino and Raspberry Pi have made this worse. I talk to a lot of people who see themselves as amateur EEs because they bought an Arduino and used some jumper wires to connect some sensors to the right pins. It's exciting. Then they lose motivation when they encounter a problem that requires doing anything more complex or custom. These people often overlap with the CS students who think the entire world of software engineering is writing CRUD apps composed of APIs connected together.
As an EE who changed majors from CS in college and who has also done a lot of programming, I can see where the author is coming from. But electrical engineering, by its nature, is a low-level field. If CS students spent their first couple years doing algorithms and data structures in assembly, they would also find it difficult!
A key purpose of the repeated exercises in circuit analysis is to build up the student's intuition for how electricity works. Mathematically, it's "simple" -- just systems of (possibly complex) equations and basic diff eq. But for sophomores, all that is still new, and most students don't enjoy going deep into derivations.
Building kits and plugging pre-made modules into microcontroller development boards is fun, but it's not really engineering. You don't hire an EE to plug off-the-shelf components together, you hire an EE to do design work, to make sure everything is going to work under all operating conditions, and to diagnose problems when something goes wrong.
Finally, software is just easier[1] than hardware. Modern software is a mathematical idealization that runs of top of decades of high-level tools and abstractions. That's why it's so cheap and popular!
[1] This does not mean that everything in software development is easy, just that you don't need to deal with physics or chemistry or manufacturing or the procurement of physical goods in order to create new software.
A key purpose of the repeated exercises in circuit analysis is to build up the student's intuition for how electricity works. Mathematically, it's "simple" -- just systems of (possibly complex) equations and basic diff eq. But for sophomores, all that is still new, and most students don't enjoy going deep into derivations.
Building kits and plugging pre-made modules into microcontroller development boards is fun, but it's not really engineering. You don't hire an EE to plug off-the-shelf components together, you hire an EE to do design work, to make sure everything is going to work under all operating conditions, and to diagnose problems when something goes wrong.
Finally, software is just easier[1] than hardware. Modern software is a mathematical idealization that runs of top of decades of high-level tools and abstractions. That's why it's so cheap and popular!
[1] This does not mean that everything in software development is easy, just that you don't need to deal with physics or chemistry or manufacturing or the procurement of physical goods in order to create new software.
I had a similar starting point to the author but ended up in totally the opposite direction, haha. Took computer engineering in undergrad and did well in both CS and EE courses. My first job was as an SDE at AWS but I hated it. Went back to school for EE, got a PhD, and started working as an ASIC designer, which I'm still doing today.
It's definitely the case that there's a bigger jump from school project to actually useful product for EE than for CS. But now that we have affordable but decently featured FPGA boards, the barrier is much lower than before, at least for digital design.
It's definitely the case that there's a bigger jump from school project to actually useful product for EE than for CS. But now that we have affordable but decently featured FPGA boards, the barrier is much lower than before, at least for digital design.
CS and EE are far too segregated from scientific academia.
I majored in Engineering Physics with an EE focus. Our classes were scheduled so we took the dependent math courses a semester before the relevant EE topics (ie: learned Laplace & Fourier transformations before circuit analysis). The EE majors all took the related math & EE courses simultaneously and visibly struggled, with every class we took together having a bimodal grade distribution.
[deleted]
A properly rigorous EE/ECE program needs the first 3 years to provide a foundation. Yes, some people get weeded out that way.
For me, a senior-level circuits class using Horowitz and Hill "Art of Electronics" was the game-changer (in 1981!). 3rd edition (2015) still looks great to me (although yes it is large and expensive).
For me, a senior-level circuits class using Horowitz and Hill "Art of Electronics" was the game-changer (in 1981!). 3rd edition (2015) still looks great to me (although yes it is large and expensive).
I feel this way about a lot of topics. Concepts are extremely fun to explore and easy to get enamoured with. But actually doing real work in some topics can feel totally disconnected.
You might love mechanical engineering and machines so you get into machining parts. By hand it is exactly what you thought, but once you hit CNC you're back to a desk job, spending most of your time in CAD software not even touching the machine.
You might love mechanical engineering and machines so you get into machining parts. By hand it is exactly what you thought, but once you hit CNC you're back to a desk job, spending most of your time in CAD software not even touching the machine.
EE is not just one area. When I was in school, some folks were studying power (100+ kv transmission lines), some folks were doing digital electronics, some were doing chip design. I'm sure there are more areas now.
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.