5 ms·

I also went to school for EE, but after a summer job doing SW, I switched to CS when I got back in the fall. I think CS (a good program) teaches you fundamenta

I also went to school for EE, but after a summer job doing SW, I switched to CS when I got back in the fall. I think CS (a good program) teaches you fundamentally how Systems work, independent of the substrate. EE is actually rather trivial compared to the complexity of big systems. EEs just learn altium, read some data sheets, and poof, out pop the circuits. Throw it in LT spice if you think it'll impress the boss. That's it. You need to know at most 2 pieces of sophisticated SW (schematic/PCB + spice). 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.

smilekzs 4y ago
If all you do is board-level integration of relatively low-speed stuff, then yes, SWE is more demanding. 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.
- spoiler 4y ago
  The stuff about needing to know a lot more physics or arcane domain specific stuff isn't so true. If you talk to someone who's got pink sunglasses about SWE, they'll say a bunch of stuff in our industry is "arcane domain specific knowledge" to them. 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
  - notch656a 4y ago
    >The stuff about needing to know a lot more physics or arcane domain specific stuff isn't so true ha ha wait until you find out about microwave engineering.
    - spoiler 4y ago
      Pardon, but I don't understand the point you tried to make... 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.
      - anotherhue 4y ago
        The failure modes are substantially different, which changes the approach. Free climbing a 5ft rock wall is not different than a 50ft one, etc.
      - GeorgeTirebiter 4y ago
        The EE domain is substantially smaller than the CS domain. It take less time and effort to be an EE "domain expert" than it does to become a "CS domain expert".
        notch656a 4y ago
        Sure, if you arbitrarily slice the pie to make it that way. The great thing is you can just semantically decide what you want to call EE and CS until your assertion is true, so you've made an assertion that is completely impossible to disprove. Bravo.
    - GeorgeTirebiter 4y ago
      You know, I'm a microwave engineer who is currently doing CS. 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.
atune 4y ago
You learn at least Altium, PADS, Eagle and some open alternatives. You learn the specific quirks of all those software. You hate every hour you have to fight with PADS' decades-old bugs and "features". 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.
na85 4y ago
Electrical Engineers also work in semiconductor design, nuclear power, RF, and a whole host of other domains, none of which are child's play. >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.
- spoiler 4y ago
  Not everyone spends their days chasing frameworks in SWE, and not everyone spends designing the next SoC breakthrough in EE. EE and SWE are both very wide paths to travel along.
- GeorgeTirebiter 4y ago
  I don't think you've ever been an EE who worked in any of those areas; I worked in Microwave & RF. Yes, it is child's play -- because you keep doing the same things over and over. 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 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.
mNovak 4y ago
That's a bit like saying SWEs just bang out fizzbuzz every day and poof, out pops the software.
- GeorgeTirebiter 4y ago
  My point is that EE is inherently simpler than CS.
randomtwiddler 4y ago
> 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. 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.
BlackSwanManZ 4y ago
"Just learn some Altium?" Really? It's like saying, just learn some python and visual code and off you to to a 400k FAANG job
- GeorgeTirebiter 4y ago
  My argument is somewhat more sophisticated than your strawman. If you fully learn Altium, I can guarantee you (since I fully know Altium) that you know pretty much all you need to know about EE, especially since every situation an EE is likely to encounter in Real Life is part of what Altium provides. 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.
  - BlackSwanManZ 4y ago
    Uhh, what? Altium teaches you how to design a battery? Teaches you optics? Teaches you RF? Teaches you motors? Teaches robotics? Knowing the software doesn't even mean you understand all of the components you can place on a board

smilekzs 4y ago

If all you do is board-level integration of relatively low-speed stuff, then yes, SWE is more demanding. 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.

spoiler 4y ago
The stuff about needing to know a lot more physics or arcane domain specific stuff isn't so true. If you talk to someone who's got pink sunglasses about SWE, they'll say a bunch of stuff in our industry is "arcane domain specific knowledge" to them. 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
- notch656a 4y ago
  >The stuff about needing to know a lot more physics or arcane domain specific stuff isn't so true ha ha wait until you find out about microwave engineering.
  - spoiler 4y ago
    Pardon, but I don't understand the point you tried to make... 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.
    - anotherhue 4y ago
      The failure modes are substantially different, which changes the approach. Free climbing a 5ft rock wall is not different than a 50ft one, etc.
    - GeorgeTirebiter 4y ago
      The EE domain is substantially smaller than the CS domain. It take less time and effort to be an EE "domain expert" than it does to become a "CS domain expert".
      - notch656a 4y ago
        Sure, if you arbitrarily slice the pie to make it that way. The great thing is you can just semantically decide what you want to call EE and CS until your assertion is true, so you've made an assertion that is completely impossible to disprove. Bravo.
  - GeorgeTirebiter 4y ago
    You know, I'm a microwave engineer who is currently doing CS. 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.

atune 4y ago

You learn at least Altium, PADS, Eagle and some open alternatives. You learn the specific quirks of all those software. You hate every hour you have to fight with PADS' decades-old bugs and "features". 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.

na85 4y ago

Electrical Engineers also work in semiconductor design, nuclear power, RF, and a whole host of other domains, none of which are child's play. >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.

spoiler 4y ago
Not everyone spends their days chasing frameworks in SWE, and not everyone spends designing the next SoC breakthrough in EE. EE and SWE are both very wide paths to travel along.
GeorgeTirebiter 4y ago
I don't think you've ever been an EE who worked in any of those areas; I worked in Microwave & RF. Yes, it is child's play -- because you keep doing the same things over and over. 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 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.

mNovak 4y ago

That's a bit like saying SWEs just bang out fizzbuzz every day and poof, out pops the software.

GeorgeTirebiter 4y ago
My point is that EE is inherently simpler than CS.

randomtwiddler 4y ago

> 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. 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.

BlackSwanManZ 4y ago

"Just learn some Altium?" Really? It's like saying, just learn some python and visual code and off you to to a 400k FAANG job

GeorgeTirebiter 4y ago
My argument is somewhat more sophisticated than your strawman. If you fully learn Altium, I can guarantee you (since I fully know Altium) that you know pretty much all you need to know about EE, especially since every situation an EE is likely to encounter in Real Life is part of what Altium provides. 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.
- BlackSwanManZ 4y ago
  Uhh, what? Altium teaches you how to design a battery? Teaches you optics? Teaches you RF? Teaches you motors? Teaches robotics? Knowing the software doesn't even mean you understand all of the components you can place on a board