Dec 7, 2006

Programming kids

Sometimes when I'm teaching kids at my mom's tutorial, I get this feeling that teaching a kid something is a lot like programming a computer.

The objective when I'm teaching is to get some concept across to the kid, so he can grasp it and manipulate it in his mind. With a computer, you want to instruct it to perform a certain task. So with this kid, you have to find a way to get the concept across, and the technique I use most often is to break it down into simpler parts which can be easily understood. E.g. to explain the concept of a conjunction (one of the parts of speech) to a kid in class 4, I would give an example of two short sentences, side by side, then show a conjunction which joins them together:

I ran. They walked.

Conjunction: but

Result: I ran, but they walked.

(I often use mnemonics too, like conJunctions are Joining words -- the `J' is the mnemonic; but that's not really relevant for computers.)

Anyway, with a computer, you break down a task, say changing the screen saver, into simple parts like: get the screen saver file name to use -- maybe from the user, or from some text file in the computer; access the Windows registry; put the new screen saver's file name into the right place in the registry; save and close the registry.

Now here is where it gets interesting. The first time round, it's almost a given that you won't get the concept across properly, and the kid will be in some kind of confusion about what you're saying. Same with a computer. It's almost certain there's a mistake in the program somewhere -- a bug. So you have to debug. This is an interactive process where you try to find out what's wrong by querying the kid/computer about what they think is going on, then you reprogram/re-instruct to compensate for that.

So, the kid says he doesn't understand the conjunction thing. The debugging always starts with making sure he knows the context that we're discussing this in; I have to make sure he knows that we need some words in the language to join sentences together to convey more information easily. (Otherwise we're forever stuck with extremely simple, one-verb sentences, each of which conveys maddeningly tiny amounts of information.)

In simple concepts like conjunctions, clarifying the context should clear up about 75% of the problems; but the more complicated the concept -- say, teaching the rules of algebra to a class 5 kid -- the more I have to go, step by step, into the parts which make up the overall concept: variables are unknowns; constants are knowns; variables and constants make up equations; equations can be solved to find the unknown by putting it alone on the left hand side; this is achieved by performing the same arithmetic operation to both sides of the equation, keeping both sides equal, and continuing until the unknown is alone on the left hand side.

For each of the above steps, I have to explain its purpose (context) -- i.e., what problem does it solve? Then I have to make sure the kid knows how to do it, and lastly of course, what to do if things don't turn out like expected. The same thing happens with computers, except of course they have no sense of context, nor do they need it. They simply perform one simple task after the other, in sequence, until the more complicated job is done. And unexpected outcomes are handled using a combination of the programming language and libraries of reusable code -- they're generally called error handling or exception handling (as in, exceptional cases).

Of course, all of the above is the ideal case when teaching a kid. The reality is I'm going to run out of time before I can properly explain the whole thing, or the kid is going to get incredibly bored and start drifting off to sleep. Maybe I can take a break then.