4 ms·

I'm an electrical engineer by trade, and do embedded systems design for a living. I do a lot of board placement and layout planning, plus writing test plans for

I'm an electrical engineer by trade, and do embedded systems design for a living. I do a lot of board placement and layout planning, plus writing test plans for verifying that what we build is good at scale. I also do a reasonable amount of debug, as that just comes with the territory. I'd say it's about 70% software time for planning and CAD work, 30% hands-on lab time. Note that it's not uniform - I might be in the lab for two months straight, then not go in for six. Generally, "embedded systems" implies some programming as well, but I do little to none of that. I think I'm the exception rather than the rule in that sense. If you wanna get simplistic about it, I spend half my time playing "connect the dots" in overpriced software, and the other half arguing with people about where I decided to put the lines. On the one hand, there's a lot more standardization in the components I string together to make a working system. On the other hand, it can be just as hard to track down the source of a problem. You happen to have caught me at a point where I'm stuck trying to figure out the proper answer to a mysterious boot issue, and let me tell you what - it's about as frustrating as frustrating gets. You have to push yourself to think hard about what you haven't done, even when you've done everything by the book. ("The book" in this context is documentation, design guides, processor reference manuals - things that tell you what to do to get your system working.) Point I'm trying to illustrate - don't think that hardware is any easier than software. It's very, very gratifying to see something real, that you can hold in your hands, work. Doubly so when people actually use your stuff and tell you how much they love it. (Yay, consumer electronics!)

posterboy 10y ago
> embedded systems > there's a lot more standardization in the components I string together Embedded Systems is just one discipline in EE. How many people design something like an lm317 deployed on embedded devices? EE tries to teach that, too, until it's all to complex not to specialize on one branch. Another discipline I was offered to specialize in was Motor Appliances and Power Amplifiers. Those don't have much to do with CS, except maybe for digital control circuits.
- cushychicken 10y ago
  When I said "a lot more standardization", I had things like DRAM or PCIe in mind, which are spec'd by their relevant consortiums (JEDEC and PCI-SIG, respectively). As in, there's clear limits on the way to make it work, and if you meet those limits, it's fine. I do a lot of POL planning for purposes of thermal management, so yeah. I'm definitely not that specialized.
  - posterboy 10y ago
    > DRAM or PCIe Well, that's also a better example for my point. the sppeds they achieve require some research
    - cushychicken 10y ago
      Maybe for a flyby topology, but I mostly work with point-to-point topologies. That's basically an exercise in good impedance control.
pepijndevos 10y ago
> It's very, very gratifying to see something real, that you can hold in your hands, work. Doubly so when people actually use your stuff and tell you how much they love it. (Yay, consumer electronics!) This is why I quit my software job and started to study EE. I'm currently waiting to get my PCB back from Oshpark. It does worry me a bit that some people here describe their EE job as more boring and frustrating than software development.
- cushychicken 10y ago
  I've heard people compare EE to building up tolerance in an addiction. As you gain experience, the thrills of discovery and problem solving end up being higher peaks, but the high is shorter and less frequent.

posterboy 10y ago

> embedded systems > there's a lot more standardization in the components I string together Embedded Systems is just one discipline in EE. How many people design something like an lm317 deployed on embedded devices? EE tries to teach that, too, until it's all to complex not to specialize on one branch. Another discipline I was offered to specialize in was Motor Appliances and Power Amplifiers. Those don't have much to do with CS, except maybe for digital control circuits.

cushychicken 10y ago
When I said "a lot more standardization", I had things like DRAM or PCIe in mind, which are spec'd by their relevant consortiums (JEDEC and PCI-SIG, respectively). As in, there's clear limits on the way to make it work, and if you meet those limits, it's fine. I do a lot of POL planning for purposes of thermal management, so yeah. I'm definitely not that specialized.
- posterboy 10y ago
  > DRAM or PCIe Well, that's also a better example for my point. the sppeds they achieve require some research
  - cushychicken 10y ago
    Maybe for a flyby topology, but I mostly work with point-to-point topologies. That's basically an exercise in good impedance control.

pepijndevos 10y ago

> It's very, very gratifying to see something real, that you can hold in your hands, work. Doubly so when people actually use your stuff and tell you how much they love it. (Yay, consumer electronics!) This is why I quit my software job and started to study EE. I'm currently waiting to get my PCB back from Oshpark. It does worry me a bit that some people here describe their EE job as more boring and frustrating than software development.

cushychicken 10y ago
I've heard people compare EE to building up tolerance in an addiction. As you gain experience, the thrills of discovery and problem solving end up being higher peaks, but the high is shorter and less frequent.