We talked about this in my software engineering course back in 2001. Surely we can start acting on these finding a quarter century later right? Right?? Joking (I guess?) aside, this really should be taken more seriously.
For the most part it is just soul crushing to constantly be interrupted but people legit die because of software errors due to these kinds of things. You think someone who has 30 minutes free a day to do code reviews for a whole team is going to do a good job, regardless of their intention?
Software is driving cars, flying planes, scheduling trains, pretty much everything in modern life. Yet we are fragmenting our codebases, micromanaging to the point of focus and productivity loss, and to make up for that we are trying to leverage ai tools that were rushed to market. Buckle up folks, we are in for a bumpy ride.
The main point I took away from your comment, and the thing that I think is missing in most of the other comments, is application of this concept to the real world. You nailed it. Always read the manual is a nice sound bite and something that can be flippantly thrown around to feel superior but that is terrible advice without any context.
What it should say is: Always refer to the manual.
Part of being a human is prioritizing tasks based on need and/or want. Another part is understanding your personal needs to accomplish a task. Reading a manual may provide value. Spending the 2 hours with family also provides value. If I choose the latter I can still refer to the manual when needed.
It drives me crazy when people double-down on some distinct thing (always read the manual) and then preach that it should always be the case or apply to all situations. There is a concept of diminishing returns and people should teach how to figure that out rather than blast out a good sound bite. Let people identify what works for them and be respectful of that. I’m not sure why that is such a hard concept for people.