Teach abstraction through concreteness
It’s a natural tendency for programmers to teach in abstraction.
Every kind of programming concept — from a primitive type to the most enterprise-level architecture — is an abstraction. It’s only until we implement something that the rules of programming become anything.
But, people don’t learn naturally by thinking abstractly. “Higher-level” thinking is the result you get from repeated experience with concrete things.I didn’t learn about gravity and potential energy, then later got myself ready to learn how to walk. Like you probably did, I just learned how to walk first. It’s much easier to start with something very concrete before working your way up to understanding the pattern.
Be ridiculously obvious
When I teach programming concepts, I’m very careful to explain things in ridiculously obvious ways. It’s too easy to run into a black hole of abstractions and layers that get in the way of the concepts we’re trying to explain. It’s natural to want to leave out concrete examples, particularly as concepts get more nebulous. There’s some fear that concreteness muddies the elegance of the high-level concept.
But, we need to start with the concrete in order to see how the elegance unfolds. This is why I’m always on the lookout for really good, real-world examples of big concepts.
If it’s relational data modeling, I always go to the School example. There’s no ambiguity, and you can get all three types of cardinality very concretely:
- 1-to-Many: A Teacher teaches many Classes, but a Class only has one teacher.
- Many-to-Many: A Student takes many Classes, and a Class has many students.
- 1-to-1: A Student has one Locker, and a Locker only belongs to one student.
Other nice by-products of the School example? We’ve got an obvious example of an unrequired relationship (A locker doesn’t have to belong to a student — it could be empty), and a great many-to-many mapping that could store other relevant data. The Student-to-Class mapping table would be the logical place to store a student’s grade in that class.
Let’s try the contrary. If we substituted Teacher for A, Class for B, Student for C, and Locker for D (the abstract approach), what do we have? Some higher-level concepts applied to a bunch of nothings. “Was it D that has or belongs to many A’s?”
As I write in The Developer’s Code, in my first programming course in college, I was taught about constructors with the unfortunate tendency of very abstract examples. For a teenager who hadn’t seen a line of code since I noodled around with Applesoft BASIC as a 7-year old…
Object myObject = new Object();
…looked very much like…
Object myObject = new Object();
It was very hard to tell what was the class name, the variable name, and the function. Something more concrete would’ve helped here, like:
Human Mary = new Human(“Female”, “27”);
That line of code works much better as a starting point. Each little bit of code is much more approachable. I bet someone could easily instantiate a guy named Tim, who just got his driver’s license yesterday. And, I bet that same person can start creating Robots named Rosie, or all sorts of Dogs, Cats, and eventually Objects.
Foo for thought
This is why I’m also against foo and bar, baz and qux. They are the Lorem Ipsum of the programming field. Lorem ipsum works in design because the point is to not focus on the actual content (Though, as a side argument, I dispute the notion that real text makes you focus less on the design). I much prefer concrete variables over metasyntatic ones, even as examples where those variables have no real meaning.
Whenever I see foo and bar, I subconsciously perform the literal translation in my head anyways — “OK, foo is just any function and bar is just any old variable”. If they were replaced with calculateArea and myCircle, I’d save myself a step in that translation.
There’s an aversion some have to concreteness when explaining something abstract (which almost all programming concepts are) because we think that the concrete example hides the beauty of the abstraction. But, the truth is in reverse. Obvious examples are the baby steps people need to comprehend where the abstractions can happen.
