When teaching new students to code, we want to avoid confusing them. Not all learning needs to avoid confusion at all times, but when dealing with a very unfamiliar subject, confusion isn't productive.
The thinking processes involved in controlling the behavior of a computer are fundamentally different from anything most people have encountered. (It’s true that there are a few students who take to the subject naturally, and a few more who want to learn it so intensely that no confusion will stop them, but we’re concerned here with teaching the ones that don’t happen to fall into those small categories.)
In the right context, confusion is a necessary part of learning. When building on a strong base of knowledge, your mind needs to integrate new, and potentially challenging, concepts into your existing mental model. It may be necessary to approach these concepts from various angles to figure out how they fit in. This is productive confusion. Having a teacher ask you questions is likely to help.
But when learning an unfamiliar skill, we want to minimize confusion. The process of fitting pieces together simply doesn’t apply, because there isn’t anything firm enough to put the new pieces into. Instead, the student learns best when led through experiences which introduce the new concepts in the simplest possible terms. These new experiences are reinforced by repetition, so that entirely new mental structures are built, just by following along.
A lesson consists of a simple explanation with multiple opportunities to practice in a supportive context. Mistakes have been anticipated, and corrective suggestions are presented as needed. The student is never expected to puzzle out unfamiliar material without sufficient support. After each lesson, learning can be reinforced by questions and discussion.
Once the student has a sturdy foundation, they can start building on top of that in various ways. But learning an unfamiliar topic is facilitated by extreme simplicity; it’s not too much to say that it can seem ridiculous to an expert.
People who are used to computers tend to acquire certain habits. They respond to user interface conventions (the configuration of buttons, links, etc) in predictable ways. They tend to move quickly from screen to screen, reading only what looks important; they know they can always go back if they miss something.
So we cater to those tendencies. Every task has three brief sections, each with a colorful header:
A “Story,” a single sentence giving an overview of what the student will do in this task. Students may not consciously read the story, but it’s a useful part of the environment.
A “To Do” section listing the actions to take, with minimal explanation: just enough to allow the student to complete the task.
An “Understanding” section, which is mostly for adult students or those who are nervous or thorough enough to want to get some context.
As the student enters each line of code, the system checks it for validity, and if it’s not valid, presents an error message.
We’ve put a lot of work into these error messages. There are hundreds of them, and each is presented in a very specific circumstance, so that the system appears to respond compassionately and intelligently (most of the time) to the user’s efforts.
As the student progresses through stages and lessons, we try to keep the process as smooth and effortless as we can. At some point the student may move beyond the point where they find programming unfamiliar -- that's our goal. They may find they enjoy writing their own games; they may experience a burgeoning sense of mastery; they may be ready for advanced topics.
Until then, we will keep everything as simple as possible.