I'm a former USN Submariner, Nuclear Electronics Technician, and served from 2006 - 2016. Boy do I have some thoughts. Not all quotes here are from TFA, some ar

I'm a former USN Submariner, Nuclear Electronics Technician, and served from 2006 - 2016. Boy do I have some thoughts. Not all quotes here are from TFA, some are from various speeches he gave. > Free discussion requires an atmosphere unembarrassed by any suggestion of authority or even respect. This has always been an interesting idea to implement at tech companies. I've not yet been reprimanded for it, but I have definitely gotten raised eyebrows when the CEO or some other higher-up makes a statement, then pauses for replies. It seems like management isn't expecting anyone to do anything other than applaud. > Responsibility is a unique concept. You may share it with others, but your portion is not diminished. You may delegate it, but it is still with you. If responsibility is rightfully yours, no evasion, or ignorance or passing the blame can shift the burden to someone else. Unless you can point your finger at the man who is responsible when something goes wrong, then you have never had anyone really responsible. This is my number one source of frustration in tech, specifically in incident management / retrospectives. Companies have fully latched onto blamelessness in such a way that obliterates any responsibility. There is a difference between blaming a person for causing a problem, and holding a person accountable for their actions. The former usually also implies a disinterest in finding and fixing the root cause, instead looking for a scapegoat. That is flawed thinking that will not yield positive results. However, it's also patently absurd to pretend that when Bob has caused 3 of the last SEV0s, Bob isn't at least related to the problem. "We need more guardrails," they'll say, and implement automated checks to prevent the specific issue. I have no problem with guardrails, but what bothers me is when the guardrails become so onerous that it's difficult to do my job, and the bottom line is no one is holding Bob accountable. If you are careless with your work, no amount of guardrails will fix that; the problem is you. > I am not satisfied with bringing an individual to a qualified level once, and then forgetting about him. Therefore, we continually reinforce theoretical and practical training with a continuing training program. This includes frequent practice in plant evolutions and casualty drills. As much as any sailor hated drills, you can't deny that they work. I was jolted awake once by the sound of the collision alarm, followed by the announcement of flooding. While it turned out that it wasn't flooding, but merely a "controlled seawater leak," (someone messed up a rig for dive and left a valve open; that's an entirely different discussion), the fact remains that everyone knew where they needed to go, and what they needed to do. Companies, especially / mostly ops-related departments, should practice scenarios. DR, loss of a K8s cluster, whatever. If you've automated everything, terrific; find something new that you haven't automated, and see if people know how to deal with it. This leads me to my next point: understanding fundamentals. > I recall once several years ago an Admiral, whose conventionally powered ships were suffering serious engineering problems, asked me for a copy of one specific procedure I used to identify equipment which was not operating properly. He believed that would solve his problem, but it did not. That Admiral did not have the vaguest understanding of the problem or how to solve it, he was merely searching for a simple answer, a check off list, that he hoped would magically solve his problem. and > One of the elements needed in solving a complex technical problem is to have the individuals who make the decisions trained in the technology involved. A concept widely accepted in some circles is that all you need is to get a college degree in management and then, regardless of the technical subject, you can apply your management techniques to run any program... Rickover understood that in order to operate things, you have to understand how they work. To this end, the training pipeline for my job began with basic algebra, in order to assure a baseline level of knowledge, and then proceeded through the structure of an atom, electrons, PN junctions, diodes, transistors, and logic circuits, before finally learning a great deal about the CPU (Motorola 68000 when I was a student; I was part of the curriculum overhaul years later to "modernize" it to the Intel 386) at the logic signal level. All this, to operate with massive layers of abstraction. But critically, that fundamental knowledge is there. We could, if absolutely necessary, troubleshoot a logic board (which are simply specialized computers) down to the component level, and desolder / resolder the new one. Tech largely operated in this manner for decades by necessity. If you asked how to do something, you were told to RTFM. If you instead said, "I read section x.y.z but don't understand what it means," there was a much better chance of someone offering guidance. The onus was on you to understand enough of your current layer to apply it to the abstraction above. Instead, we now have vibe coding, and people pushing PRs having neither written nor tested any of the code. We have people copy/pasting error messages into Slack and asking what they mean, instead of taking the 10 seconds required to read it. We have people who have successfully memorized Leetcode, but who can't apply any of that knowledge to real-world problems. Rickover was an asshole, but he had an extremely transparent and level requirement of all his employees: know your job inside and out. If you didn't, he would destroy you. There _has_ to be a middle ground somewhere that modern companies could strive towards.