top of page

How We Do It

An outline of the principles and features which make our system unique.

The principles:

  1. 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.)

  2. Coding is a craft, more than an academic subject, so learning programming is all about practice.

  3. 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.”

  4. Lessons focus on completing a concrete task rather than understanding an abstract principle.

  5. When learning is fun, students do more of it, so we teach them to create their own games.

  6. When students are ready, they are encouraged to create their own programs with progressively less support and scaffolding.

The features:

  1. Our JavaScript syntax checker is custom built for educational purposes, with a friendly user interface. No other text-based programming language we know of has a built-in, student-friendly user interface. This marrying of the programming language with user interface principles is our primary innovation. Our version of JavaScript has hundreds of specific error messages, each of which applies to a particular situation. (Other systems generally present the same cryptic, abbreviated messages that engineers depend on to fix their programs.)

  2. Similarly, our educational JavaScript interpreter (which runs student programs) has been designed from the ground up to help students. (Again, this may sound normal for educational software, but it’s the only one of its kind.)

  3. This same JavaScript interpreter includes a friendly debugger which allows students to watch their programs run one step at a time. They can see their variables change, shapes move around on the canvas, and generally see what’s going on “under the hood” with their games as they develop them. None of our competitors uses this kind of system. (Professional developers depend on debuggers to correct their own mistakes, but those debuggers aren’t friendly enough to be included in a teaching system.)

  4. 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).

    1. Our system records multiple acceptable versions of each line of code, so that, for example, it can accept either

      1. var a = b + c; or

      2. var a = c + b;

    2. As a result, whenever the student presses Show Me, we can show them the next correct line of code (one correct version of it).

    3. 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.)

    4. 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.)

    5. 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.

    6. The lesson presentation system has many links to our JavaScript documentation, teaching students to “read the manual.”


bottom of page