Earlier quoted context omitted.
This is, more or less, exactly what happened when I took Electronics I in college. The course was structured in such a way that you could not move on to the next lab assignment until you completed the one before it. You could complete the lab assignments at your own pace. If you failed the lab, you failed the class, regardless of your grade. The second or third lab had us characterize the response of a transistor in…
It's funny, because while that's a terrible educational experience, you actually learned some important lessons despite them. I remember the first time I found out that the software documentation I had been relying upon was simply and utterly wrong. It was so freeing to start looking at how things actually behaved instead of believing the utterly false documentation because the world finally made sense again.
We frequently say, don't blame the tools, it's you. That pushes "blame the tools" outside of the Overton window, and when we need to blame a tool, we're looked at like we have five heads.
Ten years ago, I was dealing with a bizarre problem in RHEL where we'd stand up an EC2 instance with 4GB of memory, have 4.4GB of memory reported to the system, and be able to use 3.6GB of it. I spent _a long_ time trying to figure out what was going on. (This was around the time we started using Node.js at that company, and needed 4GB of RAM just for Jenkins to run Webpack, and we couldn't justify the expensive of 8GB nodes.)
I did a deep dive into how the BIOS advertises memory to the system, how Linux maps it, and so forth, before finally filing a bug with Red Hat. 36 hours later, they identified a commit in the upstream kernel, which they forgot to cherry-pick into the RHEL kernel.
That's a very human mistake, and not one I dreamed the humans at Red Hat - the ones far smarter than me, making far more money than me - could ever make! Yet here we were, and I'd wasted a bunch of time convinced that a support ticket was not the right way to go.