Learning to program is a comedy of errors. It might be funny if it weren’t so frustrating. The errors are very predictable -- ultimately, very preventable. But, to a student, they often seem impossible to deal with. This is largely because of the way they compound one another.
Each line of code must be entered exactly right, or something will go wrong -- there is no room for mistakes. Most errors are simple in principle: basically just typos. Because a computer language is so unforgiving, many ways of writing an expression are not accepted that a human reader would have no trouble understanding. From a programming point of view, every expression is either correct or incorrect.
The real problem is that, when an expression is incorrect, it often will not cause any obvious problem. It doesn’t work, and it may well be breaking something, but there is no error message. The program continues on until later in the code, when, as a consequence of the incorrect line, something else doesn’t work, and an error message appears. So “debugging” often consists of tracking back and trying various fixes until you succeed in correcting the bug.
Here’s the problem: Consider what happens when a student (as happens frequently) has not one but two errors in their code. In this case, they may well track back to one of the errors, work on it, and succeed in correcting it; but because of the second error, the program doesn’t start to work.
At that point, that the student is likely to conclude that their latest experiment was incorrect (although it wasn’t), and try something new -- which breaks the program again. They are likely to continue on and find and fix the second error as well; but as long as they haven’t fixed both errors at the same time, the program won’t start to work.
In this context, an error isn’t just a learning experience, as it should be: it’s an educational catastrophe.
If the student is lucky enough to have a tutor at their side, that person can help them separate the errors and deal with them one at a time. But how can an automated system do something similar?
Blackbird Code uses a number of techniques to prevent this kind of compounded error. Firstly (as noted in a previous post), we validate each line of code separately, and we can help the student with each line separately using Show Me. But there’s one more essential tool we’ve got, which helps prevent compounding errors. It’s simple, but we’d never get anywhere without it.
Between lesson tasks, our lesson delivery system marks already completed lines of code as correct and read-only, with a gray-green gutter on the left to indicate this. When the student tries to overwrite it (which happens about once every other lesson, on average), they get a message reminding them to work on the lines of code which are specific to the current task.
It may sound basic, but this technique is essential to our approach; and as of this writing, we’ve never heard of any other online coding curriculum using it.
Most coding curriculums, particularly text-based ones, are not very experiential. They treat the subject more academically. In essence, they provide homework exercises, and a solution to the exercises, all in a convenient package. Which is certainly a useful addition to a college programming class, but it’s not enough for a younger student to be able to make much progress when working independently -- and I believe it’s a lot less than we could, and should, be doing for all our learners.