If you had picked a different degree, what would it be?

For me it would've been physics, and I say that as someone who finished the EE degree and has worked in the field for over a decade now. I did my degree in the 90s and a couple of my classmates actualy switched to physics halfway through, and I remember being genuinely envious of the electromagnetics and quantum courses they got to take that we only touched on. EE is great if you want a job at the end of it, physics is great if you want to understand why everything works. That's the tradeoff in a nutshell.

If I'm being practical rather than dreamy, probably computer science. Not for the money reasons, just because halfway through my career I ended up drifting into embedded software anyway, and I basicly taught myself the CS side on the job. Had I done it properly from the start I'd have saved myself a lot of late nights learning C properly while trying to hit deadlines. The funny thing about EE is that if you go the embedded or FPGA route, you end up writing code all day anyway, so the 'I don't want to sit in an IDE' logic that kept you away from CS doesn't really hold up. Half my week is an IDE, the other half is a scope and a soldering iron. Mechanical would be my third pick. I've worked alongside mech guys my whole career and there's real overlap, expecially in power and motors. If you like seeing the thing move at the end of the day, that's the one. As for whether I'd actually do it, honestly no. Not because EE is better, but because the specific job I have now came from a weird chain of one specific opening, one manager who took a chance on me, and a lot of luck. Rewind the tape and pick physics and none of that happens. The curiosity is normal though, I think everyone halfway through a degree runs the what-if simulation at 2am at least once. It usually means you're just bored of exams, not that you picked wrong.

Totally agree with the point about EE and CS merging in the embedded world. It’s crazy how often the line gets blurry when you're dealing with firmware. I remember a time when I was trying to fix a nasty timing bug on a microcontroller, and since I had that hardware background, I realized the issue wasn't in the C function logic at all, but how the physical power rails were dropping during the interrupt cycle. Understanding the schematic saved me days of just guessing in the code.

I find the architectural pivot quite intriguing, primarily beacuse it highlights the critical role that physical constraints play in large scale engineering endeavors. When considering the complexity of a building, the structural loads and thermal properties are essentially the physical limitations that dictate the functional layout, much like how managing the heat dissipation across a high density circuit board determines the final placement of discrete components. Do you think the abstraction level difference between the two fields is primarily a matter of scale or fundamental methodology?

If I had to pick another path, I'd have gone for Power Systems. You young folks talk a lot about embedded stuff, but before all this software bloat, we spent years designing the actual transmission and switching gear. Building the grid requires a totally different kind of thinking than staring at code on a screen. It's about keeping the lights on and managing the high current flow when everything is running at max load.

I think the point that you end up writing code all day and that your hardware knowledge handles the debugging is a bit of a stretch. Knowing what a physical power rail looks like doesn't magically help you with the complex logic of a timing bug or a broken algorithm. If a project requires low level embedded work, you still need serious software design skills regardless of whether your degree is in EE or pure CS. Hardware understanding is useful, sure, but it only gets you so far. The difficulty ussually lies in optimizing code performance across various architectures, which is a CS problem, not just an electrical one.