The guy was an absolute genius. He helped write some amount (a lot?) of the FORTRAN compiler for at least one of its variants. And... we used state of the art numerical methods. We had a textbook on numerical methods, sure, but this was always just a starting place for what we used. (To this day, I've got some numerical algorithms I coded in FORTRAN that can crush those from common libraries.) If you missed a lecture, there was no making it up by reading the book. You were SCREWED if you didn't get a really good copy of the notes.
Another thing: When lecturing, he barely glanced at his notes even in the middle of complicated derivations of error bounds and things like that.
But here's the real point of this discussion: He had a way of testing that produced similar results to what this article is talking about.
We wouldn't be tested on a general survey of the methods we covered in the class. No. We would be tested on just one or maybe two of the methods we had learned over the entire semester, and the exam questions would be a DEEP, DEEP dive into that method. (I had this guy for 3 semesters, always the same.) When asked what the exam would be on, he'd basically just say: "The numerical methods we've covered thus far". So you had no idea which method you'd need to learn to the maximum degree of depth. This forced you to simply study the shit out of them all. I mean, you had to know some really subtle things about the method if you wanted to get a reasonable grade on the exam.
I actually grew to appreciate this as a testing method. It was the first class I'd ever had where I actually really needed to study. And study I did. Every other class would involve at most a cursory review of a couple of example problems I thought I might run into. This class though was always a minimum of like 3 full days of complete and thorough review, in teams with the other students.