I always enjoy the updates to Math with Bad Drawings that reflect on the process of teaching math. The recent entry The Serious Truth About Silly Mistakes rang particularly true for me, especially when I think about teaching programming.
Orlin writes about how students do sometimes make careless mistakes – what I might think of as “typos” or “silliness” as he calls it – but that students (or, in his case, their parents) can struggle to distinguish an actual careless slip and an instance of “silliness” that reveals a lack of underlying understanding. He suggests the following for why mathematics may be particularly prone to this phenomenon:
“To some, mathematics feels like the successful performance of prescribed steps. In that case, the whole subject is mechanical and straightforward. All mistakes, in this light, are “silly” misfires.”
This description can easily apply to programming as well. The early tasks you do in a programming class can help create this mindset – you’re just getting started so a certain amount of the focus is on learning the structure and syntax of the language. If you’re focusing on reasoning out the right arguments to a method or what to set as your loop condition, it’s easy to omit a parenthesis or a comma or some other bit of syntax.
On the other hand, small bits of syntax can also have deeper meaning. You forgot that you have to call your method through an object? You didn’t declare your variable and just started using it? You have the order of your assignment statement backwards? Understandable mistakes – especially if you’ve programmed before in a language that operates differently – but also potentially reflective of, as Orlin says, your mental models still needing some development.
Orlin labels this as appeals to “silliness”; I experience this as the use of the word “just”. Many times when I work with students to help resolve a problem they are having with a program, once I’ve helped them understand the issue, they’ll declare “so I just forgot to _____”. And sometimes, it is “just” a thing they forgot to do – the carelessly omitted bit of syntax or typo they didn’t spot because they were focusing on whether their design choices and understanding of the concepts and problem had led them astray.
But I’ve started to push back on the word “just” when it seems to be softening the importance of the underlying concept that has been missed. It is a totally understandable instinct, but as Orlin says:
“Easier to admit occasional clumsiness than real confusion. But it’s the deep mistakes that signal the greatest opportunities to learn.”
If “just” gets in the way of realizing that an error reflects an insufficient understanding and the subsequent work to deepen that understanding, that “just” is a barrier to learning. I suspect it aligns with a mindset that the goal of a programming exercise is to produce a working program that meets the specification. But a more productive mindset for learning is that the goal of a programming exercise is to successfully work through the process of producing that program (I, as the instructor, already have a perfectly nice working version of the program and do not need several more), including all of the missteps that might occur along the way.
If I have done my job well as an instructor, I’ll have provided exercises that are likely to expose weaknesses in students’ mental models. But then we have to spend time in resolving the underlying misunderstanding. “Just” can be useful in defusing the tension and even self-doubt inherent in getting stuck on an exercise and create the space to be open to improving. But some care needs to be taken to make sure that it doesn’t just become the end of the process.