Though they can strike fear into the hearts of novice and experienced programmers alike, we at Bootstrap LOVE error messages, and take them extremely seriously.
For a great many learners, encountering an error message can be an uncomfortable, baffling, or even scary experience. Making mistakes is unpleasant and embarrassing, and reminds us that our code, like ourselves, is imperfect. Another reason that error messages can be scary is the fact that in many software tools, the error messages are inscrutable, opaque, or just plain confusing.
Because Bootstrap develops resources and software tools for K-12 education, clear, concise error messages were a top priority from the beginning. Students and teachers are no strangers to mistakes, and the educators we work with agree that mistakes and errors are opportunities for learning, as opposed to scary things meant to be avoided at all costs. At Bootstrap, we believe that the tools we use influence the values in our classrooms. If students are expected to learn from their mistakes and persevere, but are confounded by vague, confusing, or cryptic error messages, it becomes impossible to put this value into practice.
A major component of the pedagogy modeled in Bootstrap workshops is asking learners to read error messages out loud to themselves and their partners. This is helpful in multiple ways: first, it reminds users that error messages are there to be read: the computer derives no pleasure from scolding us; rather its messages are for our benefit. Second, it alleviates some pressure on the teachers who cannot individually respond to the questions of 30+ students in their classroom. It is much more preferable if each student who encounters an error message, rather than waiting with their hand raised for help, takes the time to read an explanation of their problem, brainstorm, and then try out possible solutions themselves, before asking for further help. This process reinforces crucial problem-solving strategies, as well as the first Common Core Math Practice: Make sense of problems and persevere in solving them.
Third, reading messages out loud is related to a technique used by many professional software developers, known as "Rubber-duck debugging". First coined in the book The Pragmatic Programmer in 1999, rubber duck debugging consist of explaining your code out loud to a rubber duck (or other inanimate object) on your desk. Even without collaborating with a partner or coworker, explaining code out loud forces us to vocalize our intentions, and much like writing test cases, it makes our thinking explicit. For a great many people, hearing a statement (as opposed to just thinking it!) makes it easier to listen to, even when it comes from our own mouths.
WeScheme and code.pyret.org (CPO) are not just tools for software development, they're also tools for learning: Learning to code, learning mathematical and geometric concepts, and learning problem-solving skills. A key component in any learning tool should be the ability to learn from one's mistakes, as well as one's successes. The direct, instantaneous feedback one receives when they make a mistake should be readable, understandable, and fixable by the user: it should be just as good, if not better, than the feedback received when everything works exactly as expected! Because we believe so strongly in this approach, we have been researching the effectiveness of error messages for nearly a decade to craft the most helpful error messages for new programmers.
Another facet in our commitment to robust learning tools is creating these tools and languages from the ground up. In fact, our custom error messages are only possible because we build our own compilers, runtime, and development environments. Because the confusing and cryptic error messages in many programming environments actively work against Bootstrap's goals of reading, comprehending, and learning from error messages, we realized that selecting a language or tool "off the shelf" would be insufficient. As a result, we continue to develop WeScheme, Pyret, CPO, and their error messages to reinforce the pedagogical philosophies that we and classroom teachers value.
So, the next time you see an error message in WeScheme, CPO, or another software tool, don't stress or despair! Take the time to read and understand what the message is saying, and what steps you could take to fix it. Although no one wants to get an error message, at Bootstrap, we relish the opportunity to learn from our mistakes, and work hard to ensure our software tools give every user that same opportunity.
Posted August 27, 2018