I imagine they'd either have coworkers who are more involved in those domains (if actually needed for the job) who can guide them on the right path or can just google their problems and end up on a path of self-discovery that leads them to those subjects. Prematurely surveying other subjects not pertinent to the job one is going to university in the first place for seems silly in that regard. I'm sure many would rather focus their time on learning more of the things that are shared in the majority of the job market (or at least more things that actually interest them).
For example, in mechanical engineering, I know how to make reliable systems out of unreliable parts. Software engineering is still focused on a hopeless quest to make software perfect. How to do it assuming unreliability has been slowly seeping into software engineering the hard way, bit by bit, over my entire career.
One example: running the brake software on the same computer that is connected wirelessly to the internet.
I have to disagree with that. One obvious example is Google, who made a fabulously reliable and fast machine out of cobbled-together ultra cheap commodity hardware, and conquered the world with it. That was in the 90s, and their way of doing things took over completely. It's why companies like Sun went out of business -- they had the super-reliable (and overpriced) systems, but nobody wanted them anymore.
What you're describing (the brake system) is just simply incompetence.
You're right about how companies managed to scale their internet server farms. But that was late (1990s) and still has not seeped into the rest of the industry.
> What you're describing (the brake system) is just simply incompetence.
I regularly discuss this with people who are convinced they can make such a system secure.
For another example, I frequently advocate on HN for embedded systems to have physical write-enable switches for reprogramming the system memory. This makes it a physical impossibility for malware to infect that memory. Nobody agrees with me. They all think they can write bulletproof code.
I can't buy disk drives with physical write-enable switches, either, not since the 1990s. This is necessary so if you try to restore from a backup drive, you can't make a mistake and overwrite the backup, and the ransomware on your system cannot write to it. This is a regression in the industry.
And yet nobody on HN thinks this is a good idea, because it's inconvenient. Or they'll suggest a software switch, which of course is inherently corruptible.
BTW, the aviation industry gets this right. The stabilizer trim has a physical cutoff switch on all their airplanes, including the 737MAX. Unfortunately, in the 3 incidents of MCAS runaway, only one use the switch properly (and you never hear about that incident). The second never used the switch at all, and the third crew decided to disable the trim system when the airplane was in a non-recoverable dive without using trim. (The electric trim switches also are physical and override the software.)
