> Is there really an epidemic of EE's who know how to use a field solver, but don't know to consider coupling between signal lines?

Now, I'm not an EE myself, just someone who took undergraduate electrodynamics, decided to read up the subject, and found some truly excellent videos on youtube.

But, at 1:00:23 in that same video I linked before (https://youtu.be/QG0Apol-oj0?t=3623), Rick Hartley says this:

> I spend most of my consulting time solving EMI problems because
most of the engineers I meet have no clue about any of this. My
job is so easy and I make such a ridiculous amount of money doing
it. It's just unbelievable; I solve most EMI problems by simply
adding returned vias to boards or changing the positions of
decoupling caps, I mean the things are so simple and ridiculous
it's amazing and if these guys would educate themselves they
wouldn't need to hire me.

So I gather that there is a problem. It's not that EEs don't know to consider coupling between signal lines, but because most of them persist in thinking that signals travel in wires, rather than in the fields, they don't understand when coupling will occur and when it won't. Sure, they can look at the result of the field solver and realize they have a problem, but without thinking in terms of fields they don't know how to solve it. So, they fix it either with trial-and-error until the field solver is happy, or by following design patterns that are passed down as an oral tradition, but without actually understanding why it works or what the problem was in the first place.

Here's an example: https://youtu.be/52fxuRGifLU?t=1719

That's simple to understand if you think in terms of fields. Even worse, if you have signal lines that are parallel and on top of one another (on different planes), referencing the same ground plane from the same side, then it doesn't matter how far apart those planes are, they're going to couple strongly since the fields overlap. You can have two traces right next to each other that have virtually zero coupling because they're stripline, or, if you have a stackup with a single ground plane on the bottom layer, a signal line on top of that, and a signal line on layer one parallel and on top of the bottom trace, they're virtually on opposite sides of the board and yet they'll couple strongly. And if you don't think in terms of fields, you'll observe that, whether in simulation or on a circuit board, and have no idea why it happens or how to fix it.

Here's Rick talking about the state of the industry in the 1980s and 1990s: https://youtu.be/ZYUYOXmo9UU?t=4295. It's clear that no, EEs weren't taught this, they didn't understand it. The situation has, I believe, improved somewhat, but only perhaps in the last decade or two. I would guess that even today, most EEs still don't really understand this (or Rick wouldn't be making so much money consulting).

> Personally, I didn't get hostility from any of their videos.

Perhaps "hostility" is the wrong word. I think on reflection "dismissiveness" is better.

Like, "Yes, we know that Maxwell's Equations are the ground truth. We were all taught that and understand it. But that's not the way practicing engineers work -- we use models like transmission lines and lumped-element. It's technically correct, but more of a curiosity than anything. It's not something we really need to think about, and certainly not useful for a general audience -- more likely to confuse them than anything."

That's the general impression I got. And I think, that not only was Veritasium technically correct, but that model is useful, and most EEs don't use it when they probably should.

Most of us here on hn are software developers. I think that most would probably agree that on the whole, we're all pretty terrible at it. Why would you think Electrical Engineering would be different? Because they're "real" engineers, whereas we just sometimes call ourselves "software engineers" (knowing that's pretty much a lie)?

Here's a presentation by Eric Bogatin that reminded me more than a little of the sort of cargo-cult design patterns that pervade software engineering: https://www.youtube.com/watch?v=y4REmZlE7Jg