Life Imitates Code. Essays by Ka Wai CheungEssays by Ka Wai Cheung from around the web.

Teaching ● August 2012

Teach abstraction through concreteness

Programmers have a natural tendency 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, most 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:

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 As?”

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.

Originally published Aug 30, 2012 at We Are Mammoth. Go to the next essay in Teaching, “Time your details”.