How We Do It
Our approach and online system for teaching coding make it feasible to teach programming more effectively, to a wider audience of students, than has previously been possible. Here's how we do it.
Our goal is to provide coding education to every student in every school.
We commit to making our services affordable to every customer.
With our system, teachers can learn and teach with minimal training in coding.
We provide all necessary professional development and ongoing support without charging additional fees.
First, and centrally, we try at all times to avoid confusion on the part of the student. Every step is as simple and accessible as possible; see this post for details. (Our insistence on accessibility, understandability, and ease of use is not shared in equal measure by other people in this space. See here for thoughts on this.)
Coding is a craft, more than an academic subject, so learning programming is all about practice. Our user interface is designed to encourage practice; and of course the fact that the system is accessible and supportive makes practice more attractive to students.
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 write their own games.
Student and teacher feedback is the key to refining the system. When students demonstrably benefit from a lesson or teaching technique, we keep it and build on it; when they complain or fail to progress, we rethink it.
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 (which 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 of code needs work).
Our system records multiple correct versions of each line of code, so that, for example, it can accept both
a = b + c; and
a = c + b;
As a result, whenever the student presses Show Me, we can show them the next correct line of code.
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 in lessons (students who want to experiment can use the Workshop, where there are no restrictions). This is a key feature unique to Blackbird Code, though its usefulness is less obvious. When a student gets stuck, they will tend to enter additional code, experimenting to find something that works. Unfortunately, even if they fix the original problem, the extra code will usually break the program -- and when the program doesn’t work, the student is likely to continue to experiment, breaking the working code. To prevent these issues, we developed a custom code editor using the excellent CodeMirror.
An entirely different type of task is a Step Task. Once the student has written some code as prompted, a Step Task can take them through the execution of the code, one step at a time, with directions, explanations, and reminders to look at the changing values of variables, arrays, and objects.
Writing a programming language was a difficult and expensive project, but it made it possible for us to create a pedagogical environment for learning: every aspect of coding has been rethought and recreated for a student user.