« Defensive Event Publishing for Remoting | Main | FolderSyndication 1.0 »

Teaching kids to program

The other day I read in Wired (which probably means it's old news ;) about a "programming board game" invented by Igor Kholodov to teach kids the "basics of programming". It's called c-jump, and as Wired says,

The board game turns players into skiers who must race down a mountain in the quickest way possible. With each roll of the die, players must follow instructions that are similar to computer program codes. Using basic math, players have to figure out which paths are open to them and then decide the fastest way to the finish line. The trick, however, is learning which paths are open to you using only programmer jargon like "if (X==1)" then you can take the green path or "while (X<4) you can take the orange path," where X is the roll of the die.
No offense to Mr. Kholodov, but I always have the same reaction whenever people talk about "teaching kids to program". That reaction is, more or less, confusion. I don't know that "teaching kids to program" is a particularly valuable thing to do, at least as most people seem to envision it. Teaching them the basics of programming, to me, involves teaching them to think logically and algorithmically, teaching them to construct mental models and extrapolate consequences, and to balance competing objectives. I don't see much use in teaching them what "x==1" means, or teaching them how to follow an if branch. The important thing is not to learn the syntax, but to learn the concepts. Not to learn how to follow an if branch (any idiot computer can do that), but when and why you might want to choose between two courses of action.

In fact, I think this concept of "teaching kids to program" meaning teaching them C-like syntax is symptomatic of a deeper problem in the industry; the idea that knowing how to program means only knowing the syntax for a language, being able to put together a file about which the compiler doesn't complain. Too many programs are constructed by trial-and-error, changing things semi-randomly until they work rather than understanding the system and considering the best method to use to solve the problem at hand.

Rote programming is not an advantageous skill; if you understand the concepts, you can pick up any language quite rapidly. Just as importantly, rote programming is something that can be effectively outsourced; there's no point in teaching your child a skill that will put them in the position of needing to be the lowest bidder to get a job. The advantageous skills are ones not unique to programming, which makes teaching them even more useful; the kid may choose to never write a single real program, after all, while mental modeling is a widely helpful skill. These skills are also the ones that tend to result in higher-paying or at least more satisfying jobs, something I think all of us want for our children. I applaud Mr. Kholodov's interest and his creativity, I just don't think this particular effort is as successful as it could be.

TrackBack

Listed below are links to weblogs that reference Teaching kids to program:

» Teaching Kids to Program, Redux from new TechBlog();
Last October I mentioned a board game called c-jump, with the following commentary: I think this concept of “teaching kids to program” meaning teaching them C-like syntax is symptomatic of a deeper problem in the industry; the idea that knowing... [Read More]

About

This page contains a single entry from the blog posted on October 4, 2005 10:16 PM.

The previous post in this blog was Defensive Event Publishing for Remoting.

The next post in this blog is FolderSyndication 1.0.

Many more can be found on the main index page or by looking through the archives.

Creative Commons License
This weblog is licensed under a Creative Commons License.