I had the exact opposite experience. The CS dept. actively recruited me, and I didn't even realize what CS was until I had completed 2 years of study. I like CS, but had I known better at 17yo, I would have gone EE or CE all the way, because that is my interest, and there is little chance I could uncover anything on my own about electronics without the structure of university. I never wanted to be a programmer, but programming is not computer science, nor does a lucrative programming career require a computer science degree, or any degree. But every where I have seen, a computer science career requires a computer science degree or a mathematics degree, but I have little doubt there is the odd physics grad or engineering grad working as a computer scientist. Just remembered, I know a guy with a biology or botany degree that works as a computer scientist on the modeling side and has for almost 20 years. But he just does modeling, not everything CS.
This so much. Programming is accessible, that's great. I learned as a stupid kid and it worked out fine economically.
But if I had to re-do everything, I'd go to school, and select anything but CS. I can always teach myself that. I find myself interested in many things nowadays, but almost never engage them, because I just can't, there's just not much an individual outside of reading.
E.g. if you got a job doing low level programming, like firmware development or even chip design (basically still programming) your EE knowledge would be very helpful.
Also at the time I went to school (2006-2008) there wasn't any soldering and very little hands-on anything in the courses I took at CMU and UMass Amherst. It was formulae and Verilog (more coding than a lot of CS classes).
In the Intro to CivE class I had to take for scheduling reasons we made a cardboard bridge and watched it fail to support the professor who was suspended over a pit. I can't remember a single ECE lab from the two years of classes I took. I learned a lot more from playing around with Arduino and such in the years after.
But that's not even the tip of the iceberg in the EE world. To name a few: high speed digital (Gbps+), ASIC (digital vs. mixed signal, RTL vs. physical design, ...), RF, precision analog, both very low and very high power, photonics, EMI... Each of these subjects require deep, arcane domain knowledge on top of physics, AND lots of grinding + experience + tacit knowledge + know-how, much more than SWE.
Source: Electronics/Embedded hobbyist with an SWE day job.
You're probably romanticising it too because it's a hoby of yours, which just leads to skwes in your perception.
Source: studied EE, after realising I wouldn't like my career paths, I switched to CS. Mostly worked as SWE tho, but I did work in ab unusual and creative EE role first, before realising that most EE jobs wouldn't be so engaging
>For a SW person, heck, there is always something that must be mastered, and pronto. Unless a SW person can kick back and write COBOL all day, there is much more to learn and apply to problem solutions. SW is fundamentally more demanding.
Surely you jest. From what I can see the "always something that must be mastered and pronto" is simply javascript kids justifying their inflated salaries by rewriting their codebases in new frameworks every few months only to rediscover bad solutions to problems that were solved a decade ago.
EE and SWE are both very wide paths to travel along.
As for javascript kiddies ---- I suppose you're right, I don't know. And I share your frustration with a new framework solving the same problems we fixed 20 years ago. I get that.
However, CS that drives the world forward -- that stuff --- is not 'turning the crank'. To the extent that any profession is 'turning the crank' --- that is the extent to which some automated systems will be doing that soon enough.
I've done EE, RF, Analog, Digital and much more. That stuff is trivial (and I mean trivial) compared with, say some of the stuff that this guy does https://en.wikipedia.org/wiki/Fabrice_Bellard
I can tell you where the 'hard stuff' is in EE: it's in getting to electronic devices & circuits that perform near the limits of what physics allows. Extremely low noise, extremely fast switching, extreme power, those areas. And, yes, those folks have to be clever. Generally, most of those people are building chips, not doing what normal EEs do -- which is connect chips together --- and gluing chips together is trivial, this is my point.
Maybe it's just easy for me, that's possible. But I'm not that smart, so I dunno.
There is a reason Marc of a16z says Software Eat World, and not EE Eat World.
In addition to LT Spice you probably learn a more specialized simulation software. Who knows, maybe you have to design power elecronics. Maybe antennas. Maybe both. Maybe in the same system. Maybe you are specialized in power electronics and you have to integrate another specialist's design into yours.
You learn about all the basic components, basic circuits and how to apply them. And yes, to "read some data sheets". You learn about the most common IC's and how to apply them, and when not to. And so on. You learn about EMI. You learn about trace lengths, placement, and their myriad of requirements in a multitude of scenarios. You learn about multilayered PCB design and its requirements. And so on.
You learn about having to minimize cost by reducing the components to their absolute minimum. You learn about having to minimize space due to real life demands of where your PCB has to fit. Maybe you even specialize in PCB design, and you apply a specialist circuit designer's schematic to the real world. Or maybe you are said specialist designer. In any case, at some point you need to know both and neither is easy.
Inevitably when you have to lock in your design, the prototypes are manufactured. Perhaps you need to assemble them yourself, certainly at least partially. You may even have just a partial device at first, which you still need to be able to wake up. Without fail, the real world reveals its ugly face to you. Despite all your simulations and meticulous design, something doesn't work like it should. You likely need to have mastery of a table full of expensive measurement equipment, and you need to know what to look for and how to look for it. After you diagnose the issue, you need to know how to fix it. You probably have to fix it manually, likely involving precision soldering work to sub-millimeter pads. After the fix, you don't hit "recompile", you fix the schematic, then the PCB, then wait for weeks or months for the next prototype round. Until then, you need to continue testing the device with hand-fixed prototypes. You need to instruct other people on how to do the same modifications.
Who knows, maybe a pandemic happens, maybe also a war that affects global economy. A chip you used becomes unavailable. There is no drop-in replacement. You have to at least replace the chip, and perhaps the circuit surrounding it. You don't just hit "recompile"...
All the while you likely have one or multiple microcontrollers in the device. You need to interface with the SW architects as well as the developer side. You need to be the datasheet for the software developer - likely you even need to write the datasheet.
All that jazz in addition to the regular stuff everyone has to deal with in one form or another.
I'm not an EE, I'm an Embedded Systems and Electronics Engineer. So I don't know 100% how to explain what they do, although I have some peripheral knowledge. Which is exactly I wrote this. I have just been in my safe firmware developer's bubble, trying to support the people designing the hardware so that they can get their side in order with the MCU's doing what they should. I have immense respect for the people who are able to make the physical side of what I write the code for. Those circuits certainly don't just "pop out".
Both sides always have something to be mastered. Both sides have their different flavors, too, but neither one is easy. Both sides have to learn and apply. Funnily enough, both sides have clear analogues to eachother, and very similar problems, just in a different plane of existence. Oh and this is just one facet of EE like others have mentioned.
I could never be a hard EE.
I'm trying to make the point that EE is a Fixed Domain, where one only needs to know a very small number of things to be an 'expert' in said domain. This is not the case for CS, which is, basically, all of mathematics that can possibly be applied to computers.
EEs will be one of the first technical professions to be replaced by robots & AI when AI moves up to white collar professions. Mark. My. Words. ;-)
The main difference are that the constraints of EE are a lot clearer than software. From the laws of physics to the lists of available parts and processes to pick from. Then manufacturability and cost.
With software, your instruction set and available system resources/hardware APIs are your only real constraints. Everything else is an abstraction which you can question and rebuild.
Turns out the "correct" way to do things fall out more readily when you have more constraints, particular because we humans are worse at constructing constraints and abstractions than the universe. You get a lot more rope to hang yourself with to use a metaphor.
So sure, if you do NOT know your tool inside and out, then that's a hacker's knowledge. To be a professional, you know your tool(s) inside, outside, and backward.
So yes, if one knew Altium inside, outside, and backward (incl SPICE sim & FPGAs), then such a person knows EE very well.
It's a small, limited domain. THAT is my point.
