Debugging the Student

Here is how I view learning:

• Learning consists of understanding a variety of concepts.
• These concepts have dependencies. Ex. you have to understand A, B and C before you can understand D.
• Think nodes in a graph:

Khan Academy’s Knowledge Graph is an example.

Success

Mr. Escalante wants to teach calculus. His coworkers say, “our kids can’t handle calculus”.

Some people believe in some sort of intrinsic ability or talent. And that if you don’t possess this, you just aren’t capable of learning certain things.

I think this is BS. For the most part.

Successful learning largely depends on traversing the knowledge graph in the right order. No single concept is particularly difficult. If you have the prerequisites, any node is conquerable (for the most part).

Unsuccessful learning is usually a result of not traversing the graph in the right order. In trying to learn something without first learning its dependencies. Or in not being able to find the dependencies. Again, when you’re taught a concept for which you have all of the necessary dependencies, you usually will understand it.

Speed

Similarly, how quickly you learn is largely a result of how efficiently you traverse the knowledge graph.

Debugging

One time someone was explaining something to me and I just wasn’t getting it. After explaining it for a third time and me still not understanding it, she said:

I’ve said everything you need to know to understand the concept. At this point I’m just repeating myself.

The great majority of people seem to think like this. “I’ve said what I’m supposed to say. If he doesn’t understand, then it’s his fault, not mine.”

I think that this approach is completely wrong. 180 degrees from the truth.

If you’re explaining something to someone and they’re making an honest effort but are just not getting it, it’s your fault, not theirs. You aren’t traversing their knowledge graph properly. It’s your responsibility to debug their understanding. To figure out what they do and don’t know, and what it is that’s preventing them from understanding what you’re trying to teach them.

Unfortunately, society seems to have collectively decided that it’s the student’s fault, not the teachers. If you watch closely, you’ll see people apologize when someone explains something to them multiple times and they still don’t get it. And you don’t have to watch too closely to see explainers get frustrated when they have to repeat themselves. But if the explainer is repeating themselves, that means they’re traversing the student’s knowledge graph along the same previously unsuccessful path and expecting a different result. Isn’t that the definition of insanity or something?

When a programmer isn’t getting the output he wants, you won’t see him blame the computer. Perhaps he’ll do so in a joking manner, but not in a serious one. Programmers know that computers are deterministic machines that produce the output they’re programmed to produce. And so, if there’s a problem, the programmer will debug the programs he’s written to find the mistakes. I think that this is the approach we need to take when explaining things to people. To a large extent, if you traverse their knowledge graph in the right order, they will learn and understand. But if you don’t traverse the knowledge graph properly, they won’t. And so if they aren’t understanding what you’re saying, you need to debug the “traversal algorithm” you used to see where it’s running into a dead end.

“Ok.” — A Story Demonstrating How Not To Debug

I once knew someone who would explain things to me like this:

“1+1 is 2. Ok. 2+2 is 4. Ok. 4+4 is 8. Ok. 8+8 is 16. Ok…”

Instead of saying “Ok.” she should have been saying “Ok?”.

She’s teaching me something that builds on itself. In between each little step, she says “Ok.” as if she’s reassuring herself that I understand it. Unfortunately, I often would get lost at a particular step and she never gave me a chance to communicate this because she just kept saying “Ok.”.

Other Factors

There are other factors that play a role in whether or not a student will be able to learn something.

Motivation. The student has to try to learn. If they don’t try to learn, they won’t learn (obviously). For example, I’m not trying to learn French right now, and indeed I’m not acquiring any French-related knowledge.

The more time you spend trying to learn, the more you’ll learn. But I think that the impact motivation has is often more subtle than people realize. Most people think “how many hours do you spend learning”. This obviously plays a big role, but so does how much effort you give at a minute-to-minute and second-to-second level. When you’re motivated and engaged, you’re continuously applying effort. When you’re not motivated, your effort level usually fades in and out, and this ends up leading to less total time spent learning.

Communication. It’s important for the student to be honest about what he does and doesn’t know, and to communicate that to the explainer. The student shouldn’t pretend to know something in order to impress the explainer. Nor should the student pretend to know something in order to avoid embarrassment. But on the other hand, it’s important for the explainer to be patient and to not pressure the student.

Short term memory capacity.

This is one bit of computer memory. Each d-shaped thing is called a NAND gate. NAND gate have two input wires, and one output wire. When the two inputs are on, the output is off. Otherwise, the output is on.

With this knowledge, you could figure out what happens when, say wire i is off and wire s is on. You just have to take it step-by-step. For example, with i off and s on, the output of 1 is on. You could continue to do this until you get the output of wire o.

But doing so isn’t that easy is it? Each individual step is very straightforward, but following the logic until the end isn’t that easy. You have to keep track of stuff in your head. Even if you write it down, you still have to do it a few times before the concepts really stick.

It turns out that the diagram above is one bit of computer memory. Wire i is the input wire, o is the output wire, and s is the set wire. When s is flipped on, o becomes whatever i is.

Now, you had all the information you needed to deduce that. You just had to try a few combinations of i/s being on/off. But again, it isn’t actually that easy because storing stuff in your head is difficult.

(Another example: look at the wiring of the ADDER and convince yourself that it works.)

Ability to store things in memory.

Clarifications

I don’t think dependencies are as black and white as I’ve been implying. Sometimes they are. Sometimes you need to understand X before you understand Y. But sometimes it’s more fuzzy than that. Sometimes X would help a lot, but isn’t strictly necessary. Sometimes X would help a little, but isn’t strictly necessary.

And in practice, it’s hard for us humans to traverse the dependency graph on such a fine grained level. In theory, it’s possible to do so and it would be optimal. But we’re limited by our brains and can’t always do this. Heuristics have their place.