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
ha ha wait until you find out about microwave engineering.
Does a software engineer have perfect grasp and understanding about every subfield in SWE? Ranging from DX to writing compilers or designing languages, SWE is an extremely broad field.
EE is no different.
I find most of these comments against my original points as me not explaining myself so well. And, I can say one thing for sure, EE's are good at downvoting! ;-)
I'm trying to say that EE, like MechE is not especially complicated. You have your theories you need to know but that's it. Yes, you can be inspired, you can figure out some trick. But: how often does an ME invent a fundamentally new mechanism? Pretty much never. How often does an EE invent a fundamentally new circuit? Pretty much never.
Now, how often does a CS person have to solve some nasty problem that has never been solved before --- every day!
I have done microwave engineering for over 20 years. I know what it takes. It's NOT Rocket Science, I assure you.
My degree (6-3) is in EECS from a small technical school on the banks of the Charles River.
So I'm not full of it when I make my statements; they come from over 50 years' experience.
EE is in a different ballpark, imagine if you had to explicitly pay attention to write software that didn't melt your CPU.
>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.
