The problem here is that in things like chemical or structural engineering, you generally don't just bodge together things by first principles.
In fact, there is a great deal of liability on the line--so much so, for example, that the guild (for what else is something like the ASME, really?) has decided "Here are the equations by which we design pressure vessels. Plug in your material--from this table of guaranteed grades and empirical data--and your dimensions, and lo, here's what you should spec."
As wonderful as it is to derive these things from equations and first principles, and as satisfying as it is to do so, do you really want to stake your career on your own from-scratch solution to a CFD problem? Or on the exact solver that you used to solve those PDEs? Or on your "hunch" as for which forces were truly at play?
Or do you want to follow the guidelines in Shigley's, Roark's, ASME codebooks, NACA airfoil reference, etc., and be able to more easily pass through a forensic engineering post-mortem?
Electrical engineering and computer science may not have had the same checkered history as some of the more established disciplines, but that doesn't mean you can't learn something from their rigor.
>The problem here is that in things like chemical or structural engineering, you generally don't just bodge together things by first principles.
The thing is, formula pluggers are unable to put formulas together from first principles because they simply do not understand them. All the book formulas are based on certain assumptions - and so the formulas will give you wrong results if your real world problem doesn't match those assumptions.
When it doesn't match the book formula assumptions, you have to derive one that does. And that requires understanding. Furthermore, you check your equations backwards and forwards using well known techniques. Lastly, you back up your analytical results by using a test rig.
Yes, I've known a lot of formula pluggers. You argue that they get rigorous correct answers. They don't, they misuse the formulas because they fail to understand them.
Understanding that is what separates a real engineer from a formula plugging technician.
What impact does this make on actual work delivered?
Seriously, we can talk about negligible leaps of quality that a guy who learns things in details has over the one who works with powerful layers of abstractions.
There a lot of workshop guys and foremen, who can repair even the most difficult problems in car engines without understand much about the physics and chemistry of things going on inside an engines. They can also build custom engines by assembling parts. Sure they can't match quality of a guy who can build everything from scratch, but get enough quality of build useful things. A lot of them can build homes.
Surely some centuries back only mechanical and civil engineers could do this. But today we have tools and techniques that make dealing with things very easy.
This is the natural graph of evolution in every discipline. Not just software but in nearly everything.
I worked on airplane design. Getting the design light and strong was worth $$$$. The extra money to pay a real engineer was nothing compared with the cost of keeping heavy objects at 30,000 feet. In electronics, shaving cost off a design you're going to make millions of copies of is worth $$$$.
Repairing a car engine is very different from designing one. There's a reason why, if you want to work on race cars on a professional team, they expect you to have an engineering degree and use it.
Designing a house isn't much engineering. There you can easily afford to way, way overbuild it to compensate for utter lack of finesse. (Funny story - in Florida they found that Habitat for Humanity houses stood up to hurricanes better. The reason? Habitat workers knew nothing about construction, and so used far too many nails.)
You're right that any semi-competent mechanic can build a working tractor from scratch, with doing no calculations at all. But it'll be either excessively heavy, or not strong enough, or cost far too much to build.
I'm not saying you should re-derive book formulas. But you are often going to encounter problems that don't have book solutions - like calculating the moment of inertia of a spinning part that doesn't match the shape of the book formulas. Or the bending strength of a beam with an unusual cross section. Then, you gotta know how those book formulas are derived in order to derive the right formula for your unusual shape.
Your alternative is to overdesign, or to compromise your design into being book shapes. Have you ever noticed that your car doesn't contain many parts with book shapes?
In fact, there is a great deal of liability on the line--so much so, for example, that the guild (for what else is something like the ASME, really?) has decided "Here are the equations by which we design pressure vessels. Plug in your material--from this table of guaranteed grades and empirical data--and your dimensions, and lo, here's what you should spec."
As wonderful as it is to derive these things from equations and first principles, and as satisfying as it is to do so, do you really want to stake your career on your own from-scratch solution to a CFD problem? Or on the exact solver that you used to solve those PDEs? Or on your "hunch" as for which forces were truly at play?
Or do you want to follow the guidelines in Shigley's, Roark's, ASME codebooks, NACA airfoil reference, etc., and be able to more easily pass through a forensic engineering post-mortem?
Electrical engineering and computer science may not have had the same checkered history as some of the more established disciplines, but that doesn't mean you can't learn something from their rigor.