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.
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.