hide

Read Next

3 Reasons Why "Computational Literacy" Is Ruining Coding Education

I was sifting through my Twitter feed recently when I came across the link to a Kickstarter project for a coding education game. The project was a well designed board game that reminded me of parcheesi. Everything from the video, to the design, to the team were excellent. There was just one small problem: the project kept insisting it would teach something called “computational literacy” to players.

For those that haven’t been paying close attention to the learn to code movement, the logic for teaching everyone to code goes something like this:

This is contentious stuff: teaching every kid to program requires that we trade some other discipline in our children’s education [1]. And this is where the term “computation literacy” was born. Those defending the need to teach young children to program don’t have a solid counter-argument when luminaries like Jeff Atwood say that not everyone should learn to program. The oft-used metaphor about everyone driving a car but not everyone needing to be a mechanic is brought up, and the programming advocates are on their heels.

In the past year, however, programming advocates have stumbled upon a phrase that appears to be unassailable: instead of programming, we need to teach our children “Computational Literacy.” Nobody can convincingly argue with the need to improve our children’s grasp of something amorphous and technical-sounding [2], and so programming advocates rally under the computation literacy flag.

Extensive vs. Intensive Learning

On nickwinter.net

In language learning, there's a slightly obscure but useful concept of "extensive reading" vs. "intensive reading". See this article for more discussion. Basically, if you are reading easy stuff quickly with very few unknown words, you are reading extensively. If you are reading difficult stuff slowly and having to either skip or look up many words, you are reading intensively.

Almost all learning materials tend towards intensive reading, whereas extensive reading is more effective and fun. It's very difficult to get large amounts of foreign language text using words the learner knows that just happen to have very few unknown words, especially in the beginning when the learner doesn't know many words. Thus the textbook. Ain't no one like the textbook. Eventually you can read a translation of Harry Potter, but most students don't get there. Especially in languages like Chinese, where reading is extremely difficult and slow and one can't rely much on cognates for unfamiliar words, learners really only get intensive reading, and their reading speeds stay very slow forever (if they don't give up entirely in frustration).

We can broaden this concept of "extensive reading" beyond reading into "extensive learning". For math, it would be very quickly doing a lot of problems, almost all of which are trivial, like one might do in a brain training game. (In school, math assignments tend to be focusing only on new techniques which are difficult, with problems that take a while to learn and do, and not many review problems.) For history, it would be reading stories about events you already know well, so that the new details are few and easily hung on the tree of your existing history knowledge. (Traditionally, "studying history" is usually about trying to absorb a ton of facts about an entirely new historical scenario, and it's hard to remember afterwards.) So on, so forth–the pattern is that properly paced extensive learning is actually kind of fun, but schools typically have to rely on intensive learning, to the detriment of retention and engagement.

What does extensive learning look like for programming? Writing lots of code you know well many times, with only a few new things here and there, not slowing you down much. CodeCombat was designed to do this as much as possible. I think we have a ways to go before it really feels extensive without being boring for all students, but we are doing a lot better than other learning methods. One key is to keep the players writing familiar code, so the pacing isn't difficult, but to keep it from being boring using gameplay. The other is to never stop long to make learners do something other than coding (like reading too many instructions or watching a long lesson).

If we think of learning programming like learning a foreign language, it's clear that you want to have a lot of extensive conversations with the computer. I think many programmers take a long time to become fluent, and a big reason for that is that they're almost always in intensive mode–writing some code that's difficult and halting, spending more time reading documentation and debugging than actually expressing themselves. CodeCombat is my attempt to save them. Our goal is that our players will be native speakers of code.

Rendering New Theme...