> But what would have to be true in a student to be able to “know” this back then? By studying! A hint is right there at the end of the quote I provided: > Th

> But what would have to be true in a student to be able to “know” this back then? By studying! A hint is right there at the end of the quote I provided: > The resulting subclasses are not yet truly general. More desirable, from a software maintenance standpoint, would be an inheritance hierarchy that models a type hierarchy This implies that the common approach at the time in OO introduced too much unnecessary coupling. And at the time and before that, there were already approaches being explored that avoided this in some way or another. Another way is to just as basic questions: What does this try to achieve? What problem does it solve? Why do they think it is a problem? How is it implemented? Can this be achieved/solved with a different implementation? Can this be achieved by removing something, like an assumption/perceived requirement or dependency? Here is a simple example for illustration: JavaScript at some point introduced syntax for classes. A relatively common "compiles to JS" language was CoffeeScript at the time, which had classes. Ask some of the questions above and others about this change. For me the reasoning for this was never really compelling. In JS you can introduce objects on the fly, you have first class functions, real closures. The only reasons I can think of for this was familiarity or other cultural ones. Another one: I've been reading and learning more about SQL lately. Trying out different types of modelling, playing with advanced features and so on. Naturally I want to get some kind of overview and look up stuff on the web. I read "anti pattern"-this and "you should do"-that. First, I was confused and started to second guess myself. But in the end I got it: Most of this stuff is written by people who just happen to work with a certain mindset and with certain types of tooling. For them these guidelines make sense, for me? It depends... In the end it's very cultural. The tools people use, the environment they work in and the types of problems they have to solve all shape the way they think and communicate. And this is especially pronounced for the academic types, or the people who mostly write documents and little code.