How We Do It
An outline of the principles and features which make our system unique.
First, and centrally, we try at all times to avoid confusion on the part of the student. Coding is a very unfamiliar skill, so we work to avoid any unnecessary mental stress. Every step should be simple and accessible; see this post for more. (This should probably be obvious, but note that the rich world is failing to teach coding to our kids, and we believe software design is a primary problem.)
Coding is a craft, more than an academic subject, so learning programming is all about practice.
The student is never asked to move beyond a topic they have not yet mastered, but instead is encouraged to continue to practice until they demonstrate mastery via “challenge lessons.”
Lessons focus on completing a concrete task rather than understanding an abstract principle.
When learning is fun, students do more of it, so we teach them to create their own games.
When students are ready, they are encouraged to create their own programs with progressively less support and scaffolding.
Lesson presentation. Each lesson consists of a series of tasks; in each task, the student is expected to enter specific lines of code. This approach is not used by any of our competitors; they usually just test that the student’s code does what it’s supposed to. (That is fine as long as the student can figure out how to do it, but if they can’t, the system can’t say which line is wrong, which makes it hard to support the student).
Our system records multiple acceptable versions of each line of code, so that, for example, it can accept either
var a = b + c; or
var a = c + b;
As a result, whenever the student presses Show Me, we can show them the next correct line of code (one correct version of it).
Challenge lessons don’t allow Show Me, so students need to learn the material to progress beyond each stage. (Challenge lessons are full of references back to previous lessons and the docs, so students can always refer back to see how to do a task if they get stuck.)
Students are not allowed to enter additional lines of code -- another feature unique to Blackbird School. When a student gets stuck, they tend to enter additional code, experimenting to find something that works. Unfortunately, even if they fix the original problem, the extra code will often break the program -- and since it doesn’t work, the student is likely to continue to experiment, breaking the working code. Our student code editor (made with the excellent, open-source CodeMirror), prevents these issues. (Students can also do Guided Projects, offered after each stage, or experiment on the Workshop. These environments allow students to freely enter code.)
An entirely different type of task is a Debug Task. Once the student has written some code as prompted, a Debug Task can take them through the execution of the code one step at a time, with explanations.