Hacker News new | ask | show | jobs
by exmadscientist 1917 days ago
Why push yourself through a degree-style path? So much of what EEs learn in their coursework is of low utility. (I'm a physicist who transitioned to working as an EE. I have never had a single EE course, and yet I find myself with no obvious deficits compared to my colleagues who have.)

There are two ways to learn an existing technical-ish subject: you can spend a lot of time reading textbooks, then do some projects (the "slow-fast" approach); or you can dive in to projects and refer to textbooks when you get stuck (the "start-stop" approach). In the slow-fast approach you will go slowly through a lot of textbooks for a long time, and then in theory you will be able to do projects very quickly once you are done. In the start-stop approach you will start a project, quickly get stuck and spend a while searching for and understanding the answer, then go back to your project.

In my opinion electrical engineering, being a subject where fast feedback is generally possible, is very well suited to project-first learning. I would recommend grabbing a few textbooks (Horowitz and Hill's Art of Electronics holding pole position for a practically-oriented learner, in my opinion), reading their introductory material (table of contents, preface, etc.; enough that you know what each book has in it), and then setting all the books aside until you need them. Avoid books targeted at "makers"; most are fine but a sizeable fraction are written by people with no clue what they are doing, and they will actively set you back. (It is very difficult to learn from an author who does not themself understand the subject, and all the worse if they do not realize that they do not understand. Since there are plenty of better sources out there, it's little trouble to just avoid the whole class.)

Trying to work on brain-computer interfaces is challenging because it blends biology with electrical engineering. The biology will naturally drive things, because you cannot really control it like you can the electronics. So learning EE in this context is about two things: 1) What can I do with circuits? and 2) What do organisms behave like and respond to electrically? Your project is then using your knowledge of circuits to solve R&D problems relating to bioelectric signals.

This isn't easy (I think you know that), but the benefit is that you can quit with "just" EE skills and still come out ahead.

10 comments

As a practicing EE / RF comms engineer, I will say that it is very obvious when you're working with someone who thinks that their EE coursework wasn't useful for the real world.
As a practicing EE (power systems), I agree. It often becomes clear when someone is unable to distinguish a practical limit (this equipment is not rated for X, our operating procedures prohibit doing X) from a physical one (X is not possible because of underlying physical principles).
This. There are so many real world, practical, and pragmatic uses for EE. This example, which is basically knowing that the hardware specifications cannot meet the claims that are being made about a product, in an accurate or reliable fashion, is one I use on an everyday basis.

You don’t fall for marketing gimmicks.

Another thing is you know the relative price (ballpark figure) of the technology, as in how much it costs to make something, often just by eyeballing the actual product or by looking at its specifications. Sometimes this translates to more abstract and somewhat unrelated fields such as medications (if you read the patents and study them).

Yeah I have run into plenty of EE's who don't understand how to model a simple filter, for instance.
The first interview question is always an RC filter.

It's an easy leading indicator of who has their shit together.

RC filter is like fizzbuzz for EE.
One of those is a basic building block used in pretty much everything, the other is software bullshit.
Looping through a list of items, and doing different operations based on their value is an extremely common occurrence, and you’d hard pressed to find a codebase that doesn’t use that pattern somewhere.
I feel attacked. I'm a DSP engineer and I haven't implemented an analog filter since I graduated. If we got into detail on RC filter gain and phase shift I'd fail. Do I have to give my EE degree back?
fizzbuzz is literally a filter, albeit digital, and it involces a circuit, well a loop in most realizations, too.

It's probably at the same level of complexity, give or take.

And, like fizzbuzz, lots of people fail it.
yep exactly, even with training and degrees and claims of competence
> (I'm a physicist who transitioned to working as an EE. I have never had a single EE course, and yet I find myself with no obvious deficits compared to my colleagues who have.)

Not to dunk on the rest of your reply, which I agree with, but there is a humongous overlap between your typical undergraduate physics and electrical engineering degree, and I think you're able to be successful because they're so similar. Academically, the required courses are mostly identical until your 3rd year and if you choose an RF, microwave, or semiconductor physics specialization it's just more of the same applied physics, so it would make sense you would easily be able to pick up the concepts necessary with experience.

No. I disagree, and I’m a Physics SB and PhD (lasers). EE is a discipline unto itself. A stack of physicstextbooks and coursework is useless when you need to build a circuit that does what you need. Indeed, even writing down the desired circuit specs in a reasonably professional manner has zero overlap with physics.
If it's just circuit design, the difference between an EE and a physicist is 6-9 credit hours of courses. You will both share all the necessary prerequisites in mathematics (mostly Fourier analysis, linear algebra, basic statistics, and differential equations) and electromagnetics.

New graduates in EE also can't do the things you listed :)

6-9 credit course of courses and you’re a circuit designer? You are dreaming. Which capacitors are used for what function? What kind of trouble can you get into if your comparator is too fast? Do they tell you that a 7800 series regulator needs a load? Going to school is good. But if the alternative is 6-9 course hours, I’ll get further with scope, meter, soldering iron, app notes, and LTSpice in the same time than that student. And I assure you, from the bottom of my heart, as a near-expert in both, that the Fourier analysis in quantum mechanics, solid state physics, optics, etc. bears little resemblance to that used in signals and systems and DSP. LITTLE. RESEMBLANCE.
> New graduates in EE also can't do the things you listed :)

That was the spirit of my point, yes :)

More than once I've heard a coworker complain that "I wish I had learned about that in school instead of [filler course so useless that I forgot what they said]."

Very good point. Often I think the hardest part about being an EE is using our CAD tools.
Also perhaps units conventions etc may be different in EE and Physics, like use of Gaussian units in electrodynamics in Physics, and also things like the mysterious 'Z'-transform that seems to pervade much of EE.
Gaussian units seem to be on their way out. I, for one, won't miss them. (Or cgs.)

The Z-transform is much more related to the others than is clear at first glance. This post on transforms [0] from the The n-Category Café is fascinating, and my go-to for understanding what the Laplace transform really is, even if I don't quite grasp many things in the post. (And I also have a math degree! But not a graduate one in active use, as most of the people around there do.)

https://golem.ph.utexas.edu/category/2019/07/what_is_the_lap...

> the Laplace transform is really just a generalization of the familiar Laurent series representation of complex analytic functions, but where the exponents are allowed to be non-integers and to “vary continuously” rather than discretely.

I understand some of these words... they're very familiar to me...

I'm saying this as someone who's dealt with the discrete and continuous time Fourier transforms, and Z-transform, and wants to get into Laplace transforms.

https://golem.ph.utexas.edu/category/2018/02/mlab.html

it might as well be from a random text gwnerator

Gaussian units make physics prettier.

“Avoid for new designs”

Only now I had noticed, in the Gaussian system, the unit for capacitance is centimeters.
I have undergrad degrees in EE and physics. There is barely any similarities besides a class or two in electrodynamics.

I even went a step further with how involved with physics I was during the EE degree and specialized in RF; hardly any of that was covered in my physics degree.

I think it’s eye opening that physicists cannot explain how a computer operates physically lol
> but there is a humongous overlap between your typical undergraduate physics and electrical engineering degree

As someone who has a degree in both: Hard disagree. The physics curriculum had one course on circuits/electronics combined, and they covered almost nothing practical when it came to tools like oscilloscopes, etc. Few physicists I know have heard of "3db point". No statistics in the physics curriculum (no, quantum mechanics and stat mechanics don't count). Absolutely nothing with regards to digital, communications, or control theory.

The only real overlap was math, EM and semiconductors. Most people who get an EE degree are not targeting that world.

I'm a physicist too, and learned electronics on my own. I don't have an engineering job title, but have done fairly extensive design work. In my workplace, I'm the go-to person for anything analog and quantitative, such as figuring out a noise budget for a measurement system, as well as for figuring out how to prove that it actually works. Horowitz and Hill had a chapter entitled "digital meets analog," and there should be another chapter, "analog meets physics."

Like others have said, there's a lot of overlap, especially for experimental physicists, which is what I studied. The stuff that makes studying engineering hard for a lot of students is the math and physics.

There are subjects that we don't learn in physics, such as control theory. Yes, that's worth learning. I defer to engineers for really hard feedback control problems. My approach is instead, to design the hardware so its physical characteristics make the control problem easy. That's not always possible.

One reason why we can find a way to fit in, is the huge diversity within engineering itself, leaving some niches that look a lot like what physicists do. When I taught in an engineering department for one semester, the professors always had their latest papers posted outside their office doors, and I noticed that one prof seemed to publish everything in Physical Review.

Out in the work world, a lot of people with engineering job titles don't really do engineering: They can be quite busy and productive, and rewarded, for basically arranging things, fitting things together, troubleshooting, dealing with vendors, and so forth. In fact, they can get so busy at that stuff that they forget their math and theory, leaving the physicist as the go-to "math person" when a quantitative problem needs to be solved.

Then there are what I call the real engineers, for whom the engineering skill is accompanied by an attitude and discipline about making things safe, reliable, maintainable, and traceable to documented and published information. These are the ones who won't accept a measured value, but need to see it guaranteed on a data sheet. I'm not that kind of engineer, and I admit it. And we definitely need that kind of engineer for systems that potentially involve public safety or massive economic liability.

> a lot of people with engineering job titles don't really do engineering: They can be quite busy and productive, and rewarded, for basically arranging things, fitting things together, troubleshooting, dealing with vendors, and so forth.

In my work, the title "manufacturing engineer" title goes to people that work all day (and at a hard pace) doing nothing other than working in the PLM system, orchestrating ECO bureaucracy, and BOM work. To them, the actual products are nothing more than a collection of part numbers and rules applied in a cumbersome framework. I almost feel sorry for them. The sad thing is, there's an increasing population of these types, along with product/project managers and supply-chain specialists, while at the same time a decrease in engineers and techs.

I also have a physics educational background and make my living doing a weird mix of EE, software, and failure analysis work. I love my job, I see myself as a kind of general purpose problem-solver. Unfortunately actual hands-on technical generalists, IMHO, are in a downward spiral these days as far as status within large organizations goes.

The OP, I hope, is aware of this. He might be happier specializing in his interests and teaming up with other specialists who focus on EE.

Something I keep thinking about is that 100 years ago we had a huge cadre of workers called "clerks," whose job was basically to gather, organize, and transfer information. You'd think those people would be replaced by computers, but there's always a bit of complexity in each transaction that needs the human touch: Does this ECO make sense, for instance.

Outside of engineering, a lot of people with "manager" titles are similarly engaged. Their supervisory work, while important, is about 4 hours of work per week. The rest of the time is spent on tasks assigned to them, such as creating a new process for replenishing the hand sanitizer, or approving documents.

It's just that we believe that by now we should have eliminated clerks, so to make ourselves seem modern, we re-title them engineers and managers.

they are titled engineer if that's what their diploma says, which is indeed not that rare, and maybe paires well with software engineers fresh out of college who fail fizzbuzz (as mentioned before in this thread), precisely because so much of software engineering is glueing packages together.

I'm not saying that's a bad development. It's just what it is, probably follows a smooth bell curve distribution of expertiese. The hard stuff is just, like, really hard (as is English!)

I think it's an inevitable outgrowth of complexity. If the number of pieces grows by O(n), then interactions between pieces grows by O(n^2). It doesn't take much complexity before gluing pieces together becomes the dominant activity in an enterprise.
> The sad thing is, there's an increasing population of these types, along with product/project managers and supply-chain specialists, while at the same time a decrease in engineers and techs.

This makes total sense to me. The bulk of time I’ve spent on many projects goes into supply chain management and factory coordination. I can easily see how the work of one engineer can keep 10 people like this busy full time.

I can't recommend The Art of Electronics highly enough - it's way more intuitive and informative than any other resource on the subject I've found. It's exceptionally great when paired with the self-paced lab manual Learning the Art of Electronics[0].

[0] https://www.digikey.com/en/resources/edu/harvard-lab-kit

I'll second this, despite the first version being written over 40 years ago it's still one of the best books I've seen on the subjects.

The more recent versions bring it up to date well, it's a dense book but one I find myself coming back to more than any other for the incredible depth of practical engineering knowledge.

Unfortunately these kits are unavailable from either digikey or mouser, because they include various obsolete parts which are no longer sold.

Here's the website for the book https://learningtheartofelectronics.com

It definitely depends on what you want to do. If you really want to design RF or analog circuits, having a mastery of undergrad EE signals and systems courses would be helpful. But if you only want to make digital logic work, you only need some basic knowledge of circuitry.

EE is a vast field that encompasses everything from high power transmission to designing semiconductors. Even full course work from undergrad to PhD in EE is going to be fairly specialized.

All that being said, I agree that if you just want to learn how to build a catalog of reasonably simple circuits, learning academic EE is a waste of time.

> analog circuits

Can you expand on how analog electronics benefits in particular from a formal EE education? I build analog circuits (amplifiers, filters, power supplies mostly) very frequently in my job as a physicist. We have to care about noise so I've picked up a knowledge of how to deal with it in analog circuits. Is there some other area of analog electronics that "hackers" like me might not get exposed to, compared to an EE undergrad? I'm thinking of moving into EE and would like to work out the gaps in my knowledge. I also ask because I can see obvious reasons why your other example - RF electronics - would benefit from formal training but none for analog electronics.

Physics and EE have a lot of overlap and exposure to analog circuits in undergrad is pretty shallow. There will typically be a class that covers RLC and switched circuits in time and frequency domain and the basic uses of amplifiers and filters. After that it's theory applied from Fourier analysis and control theory and then they'll have a class on semiconductor physics and another that covers basic amplifier design. These days a lot of focus is on integrated chip design instead of board design. As far as most board level design these days, someone coming from a physics background will pick it up just fine on the job or in the lab as long as you have solid fundamentals.

More advanced stuff that you probably lack vs a practicing EE or an EE graduate education is going to be edge cases, advanced stability analysis, translinear logic and exposure to all the different types of component design. There are tons of different types of say amplifiers used in specific applications whereas most people working in a lab just slap opAmps on everything. A lot of advanced analog design is just applied control theory. Also keep in mind that these days Digital, RF, and Analog all blur a lot in a cutting edge design environment.

Quick Edit: A lot of the more traditional EE design companies will consider someone with a physics degree to be equivalent to someone with an EE degree unless they are looking for a very specific niche.

Thanks for the reply! Happy to hear they might consider my physics background. Stability is another thing I have to deal with a lot.
Probably not. I'm thinking of things like Laplace transforms and their relationship to differential equations, and stability analysis for things like amp feedback. Most of that you should have gotten academically in physics, just with a more specialized application when applying it to how you model an inductor or capacitor for instance.

But if you can design an amplifier or power supply, you probably already understand how to think of all the basic circuit elements and write down a differential equation modeling the circuit behavior.

With respect to RF, it's also a large field. In lower frequency regimes you can model everything as a lumped circuit element. As you get into higher microwave frequencies, you start needing to worry about modeling things as a distributed circuit. If you are focusing on things like antennas then you need to know more about electromagnetics. These days practicing engineers dealing with things like antennas and feedlines typically model them with computers. In some ways RF analog circuitry is disappearing as ADCs and associated digital circuitry are becoming advanced enough to swallow large bandwidth signals.

In many ways EE is pretty close to "applied physics", just focusing more on emag and less on mechanics.

I don't tend to dig down into equations and just use the simple heuristics I've built up from examining other designs. I guess with a bit of practice I could do it though. Thanks for the info!
That's a good point. The project-first approach worked very well for me when learning new software frameworks/libs/etc.

My main concern with EE is that once I'll get to the brain-computer interfaces, I'll be in a situation where there aren't many off-the-shelf components/solutions available, and at the same time I'll likely need to know how I can push physics closer to the edge. I suspect I may need a better theoretical foundation to do that.

That said, I definitely like the idea of focusing a lot on hands-on projects.

You are not going to start anywhere near the area where you have to go "full custom". That is, you won't be spinning custom ICs, you'll be assembling custom PCBs from off-the-shelf components. Possibly expensive ones. But that $1000 OTS part is an insane bargain compared to any chip fabbed just for you.

First make your thing do something, anything at all. Second, make it do something useful. Third, make it do the right thing, the thing you need, your goal from the beginning. Only then should you optimize it, making it smaller or cheaper or lower power or prettier or.... This is the road to success in the "R" phase of R&D.

I'm interested in how you found the transition from physics to EE. Did you target any particular "entry" jobs in the industry that were more genial towards physicists for instance? I'm a physicist with some electronics experience and I've got the idea to move into some EE-related field one day.

And +1 for Art of Electronics, it's the bible for physicists working with electronics.

Also, there are big differences within the field of just something like analog signal processing, which will be very important for this project. The textbook linked (Sedra&Smith) is great if one plans to pursue analog in VLSI but not so great if one wants to do it on a PCB (I think Franco’s amplifier text is way better here).

Brain-computer is going to be very tough, even ignoring all the safety and physically wiring into a brain stuff. The signals are irregular, weak and fast which makes them very difficult (but not impossible obviously) to measure.

I think it's way more about what suits the learner than what suits the subject.

I studied EE, and got on better with the the more theoretical textbooks than I did practicals ('huh, ok.. why?!').

>or you can dive in to projects and refer to textbooks when you get stuck

You dont know what you dont know. Its better to at least read all of the coursework even fast and without understanding than go green and make basic I didnt know that existed mistakes.