The Hardest Thing About Teaching: Knowing When to Lie

A model, by definition, is a simplification, otherwise it wouldn't be a model (it would be the actual "thing"). Therefore, you shouldn't get caught up on whether or not the model is a perfect representation of the thing it describes (because it won't ever be), but rather if it is useful in the situation in which it is being applied.

For example, sometimes it is useful to model light as waves, sometimes it is useful to model it as particles, but both models are technically wrong because they can't explain the full behavior of light by themselves. That doesn't mean we should just give up those models and never use them, since they both are useful in certain situations.

So present the simplified model to the student, until that simplified model no longer can explain what you are trying to explain. In which case you present the more refined model. Just keep in mind there is overhead that comes along with that refined model.

And perhaps more importantly: don't think in terms of "truthfulness", think in terms of "usefulness".

I teach programming through video courses, and at a very beginner level, you have to lie a lot, in order to simplify the concepts that are peripheral to the core concept you are trying to explain. There are few things (if any) in the world that can be explained linearly. The dependency graph for any concept you want to teach will branch out into a dozen other topics, and often cycle back on itself.

The way you have to teach is pick a core concept you want your student to learn, and do your best to explain it, and whenever an unexplained concept comes up, explain it the simplest way you can so you don't get knocked off track. Often this involves lying, or creating the simplest mental model that works for the current situation.

I'll get emails routinely from people who say that I didn't thoroughly explain some topic that was not the core topic of the exercise. For instance if you want to learn about JavaScript strings, you may want to mention "string".toUpperCase(), but if you are just learning about strings, functions or method invocations are some way off in the future. You can't just stop and explain the details of functions, how they are invoked on objects if you are still working on the basics of a core data type.

So the hardest thing is not just knowing when to lie, but how to lie in a way that won't cause too much upset if the student knows you are lying. The best way to mitigate this is to explain that it is a simplification, and we will learn more about it soon. This is usually enough to keep going, as well as keep interest levels high.

My propositions serve as elucidations in the following way: anyone who understands me eventually recognizes them as nonsensical, when he has used them - as steps - to climb beyond them. He must, so to speak, throw away the ladder after he has climbed up it.

When you're trying to explain something, you can be too simple, you can get way too complex, you can qualify your simplification to the point where the explanation is lost, or you can simplify just enough and not spend time discussing the limits of your simplification until you've made your point.

That last item is the "when to lie" bit.