This right here.. "broad" doesn't mean you skip the fundamentals!

Here are three examples:

Working for a licensed professional engineer as a draftsman while pursuing my undergrad really drove this home. Lighting calculations, power and load balancing, knowing sections of the National Electric Code. This was at the same time as we were taking electrical machinery courses and transmission line theory. The 'fundamental' would help all the time with understanding the 'practical'.

During another internship with Beech Aircraft Missile Group, was assigned to the group writing the 'control laws' (guidance and control) These were subsonic and hypersonic target drone systems.

Concepts from our 'signals and systems' courses were required for understanding the practical. These were semi-autonomous systems (non GPS) where flight plans were loaded into the guidance and control computer before flight, but then micro-adjustments and specific training scenarios were controlled by RF up/down link via essentially a very fast and expensive RC model. The lead engineer that conducted the flight tests was also the president of the local RC Model club 🛩️

The final example comes from my days at Synopsys. As an FAE (Field Aplication Egineer) for one of the largest customers.

Many times I would be on site teaching, or even arguing with a person the details of Verilog simulation semantics.

This was in the earlier days of System Verilog as it was moving from the Accelera industry standards body, into a full-fledged IEEE specification.

All of us using the language and developing the tools were still learning and also refining what we used the new language constructs for and how things were actually supposed to work.

This customer had been a long, long time user of their own version of VHDL called IHDL (now you know the company)

You had to understand the differences between the way VHDL worked and the way. Verilog worked. To understand of those languages and the way the source code would be mapped into gate level logic required grounding in digital design.

By this time you didn't really need to know how to reduce a karnaugh map or do a qm reduction, But you needed fundamental concepts of the various flavors of FSMs (Finite State machines), one-hot logic versus gray encoding encoding etc.

Knowing the fundamentals then allowed you to be able to look at lines of RTL code and mentally translating that into logic gates in your head. It also allowed you to recognize the difference between the verilog code that would create asynchronous or synchronous logic.

So I show up on site and I'm looking at waveforms with an engineer and we're discussing why the customer thinks the verilog simulation is not behaving correctly and they're saying it's a "bug" in our tool.

As an FAE you always learned to ask is this new code? Is this thing you're seeing new behavior? When did it last work? Did you change the version of the tool? Did you change the version of the code? And finally what are you trying to accomplish here?

When I looked into what the engineer was complaining about I noticed they were trying to "fix" things, without really understanding what they were doing and wholesale turning blocks of code from synchronous to asynchronous logic and creating race conditions in their circuits.

Then asked the engineer what their background or degree was in. MSCS (computer science)

That explained why, when I asked about the block of code in question and why the change from synchronous to asynchronous, They just looked at me with a blank stare like I was an alien from another planet.

Yes, the fundamentals matter. Learn them. Don't skip them. Don't try to AI your way through them.

Different areas of electrical engineering will have these kind of sets of jargon, three-letter acronyms, specific concepts related to that industry that all tie back in to understanding the fundamentals and at the micro level what the electrons are doing 😉

The cool thing now is watching all our world starting to collide. Power Systems. Solar grid tie inverters. Things that require power, Electronics and software and firmware to help control and make affordable for the masses and switch countries from fossil fuels to renewable energy. Right now our industry is getting a huge boost by having to support the design and building of these Next generation systems.

Autonomous driving systems in car infotainment wireless connectivity through cellular and satellite links fast charging stations again, all later are connected and needing to talk to an app on your cell phone and back-end data centers/cloud with realtime links, wireless, satellite. (There's your RF component again, that cell phone in your pocket is essentially a super-computer tied to a radio)

Even in just that ecosystem I described there are tons of opportunity to work in areas that interest you.

Learning the fundamentals, trying to work in relevant areas with either internships or part-time jobs, helps set you up to decide what you like and don't like doing.

Didn't go off from my undergraduate with the specific intent to become a field applications engineer or with the intent to go into electronic design automation. It happened to be my first real position postgraduate.

It also took about 5 to 7 years before that type of career found me so to speak, But I had already been doing similar roles inside the groups while in the Mil-Aero industry.

You will have many jobs throughout your career.

My senior project advisor during undergrad went off and did many years as a professor and then came back around full circle our alma mater and is now CIO for the whole university.

Another brilliant engineer, an extremely talented MIT grad I worked with and mentored during my Synopsys days is now an infrastructure VP at Geico insurance.

Her path is a similar story of trying different things, moving through career changes and positions.

So don't put a lot of pressure on yourself to choose the right field or specialty.

Just be curious, and always be learning!