I read the DoE biography of Rickover while I was doing my undergrad in Physics at the Naval Academy in the 90s. At that time there were still Navy Captains who had interviewed with Rickover. And I've read pretty much everything I could since. I would say the lessons left behind are more for managers, unfortunately most managers will never read them. They're too busy showing how they can do more with less. Cutting corners is their method.

> At that time there were still Navy Captains who had interviewed with Rickover.

After nearly 50 years I can still recite my interview (both sides of the conversation) pretty much verbatim from memory — it was, let's just say, unfriendly (but he let me into the program, much to my surprise).

Wow! I’d love to hear it.

Would love to hear it too

I think a lot about how the modern software solution is to automate all of the things.

Rickover believed in that AND demanded technical excellence from all of the operators. Nowadays, it seems like we automate things so that we don’t have to train technical excellence.

Rickover believed that automated systems will fail in unpredictable ways, leaving the human operators as the last line of defense. The people in the organization need to understand how -everything- works so that they can respond to these failures.

But modern orgs want to automate the things so that they can cut costs. Not Rickoverian.

I'm a former fast-attack sub nuke (Electronics Technician). Note that I got out in 2016, and was last on a sub in 2013, so cultures may have changed.

Nukes are expected to understand their systems (and everything that interacts with them) at a granular level. A common final board certification question is, "How does a neutron turn my rack light on?" Depending on your rate (i.e. your specific job - reactor, electrical, mechanical, chemical), you may be expected to do a deeper dive into a specific area, but everyone will be required to trace the path from fission --> heat --> heat exchange --> steam generation --> turbine --> power buses --> light. By trace the path, I mean literally sketch the systems including pumps, valves, circuit breakers, etc.

An analogous question for tech is "What happens when you type foobar.com into your browser?" This question has enormous breadth and depth: keyboard debounce circuits, CPU interrupts, TCP congestion control algorithms, DNS, LCDs, and a thousand other things I didn't discuss. You can argue that this is all trivia for most SWEs, but I counter that if you have at least a passing familiarity with the actual full stack, you're in a much better position to understand how your day-to-day work affects and can be affected by the rest of it.

For example, IOPS seem to be a mystery to a lot of devs. I'll grant you that EBS (and presumably other cloud offerings as well) makes it a fun adventure between provisioned, burstable, implicit striping, max performance/24 hours limits, et al., but the root concept remains the same - you can perform N actions/sec of block size M. Don't forget to take fsync() calls into account, as well as blocksize mis-matches.

This stuff is so abstracted away that most people never have to see it or think about it, until they do. The magic that's occurring when you add a Persistent Volume to a Pod is incredible. There's the cloud provider abstracting away the disk, controller, redundancy, failover, etc. The CSI driver abstracting away filesystem creation, expansion, etc. Kubernetes abstracting away mount points, access controls, read/write, etc. The amount of things in the path between your app issuing a write and it landing on persistent storage is breathtaking.

Not having to deeply understand lower level activities allows people to concentrate on higher level activities, enabling the building of more complex systems. I suppose it is good to have a few people who know everything but it suffices to have collective coverage with redundancy. Unless you have severe constraints on the size of the crew, as with a plane or a submarine. The software world is not like that.

I didn't say it's necessary to deeply understand everything.

> if you have at least a passing familiarity with the actual full stack, you're in a much better position to understand how your day-to-day work affects and can be affected by the rest of it.

Sweet I was a submariner; QAO/DCA type and now a reservist. Love running into other submariners in the HN comment section.

One of the places Inworked at was so good at cutting corners, they had to resort to cutting corner of a perfect sphere after no corners were left anymore. In a sense, the culture / leadership principle of "no corner cutting" was 100% accurate... Horrible place, and all engineering driven...