Sally Fincher (the head of the computing education research group I work in) has published a very interesting article (originally in CACM, public version available here) about the lack of good research in computing education, and her worries that much of our efforts to push computing into schools lacks backup from researchers on how best to actually teach computing (and programming in particular):
What is resolutely held common [between teaching computing/programming literacy and] traditionally formulated literacy is that these approaches are unleashed on classrooms, often whole school districts, even into the curriculum of entire countries—with scant research or evaluation. And without carrying the teachers. If we are to teach computing in schools we should go properly equipped. Alongside the admirable energy being poured into creating curricular and associated classroom materials, we need an accompanying set of considered and detailed programs of research, to parallel those done for previous literacies.
I really enjoyed the article, which challenges some of the rest of our approaches to delivering and researching computing education — I highly recommend reading it.
Having read it, you might well wonder why there is so little research into school programming education. There are several reasons for this. One is that computing education research is a small field even within computing, and compared to something like literacy research it is tiny indeed. Another problem is that until recently, computing education researchers had no compelling reason to look at teaching introductory programming to all school-age students, because nobody was trying to deliver such teaching; instead the researchers were mainly focused on the status quo of teaching programming to self-selecting undergraduates. (As an additional practical issue, it is famously hard to get funding to research computing education; computing research funding organisations haven’t generally viewed it as an important area, and it was considered too niche for education research funding organisations.)
There is a further issue in teaching programming. Many concepts in programming remain reasonably static (e.g. variables, functions, collections, iteration, recursion), but all around them there is innovation and evolution. You have people toying with different syntaxes, different representations (blocks, frames, text, etc), different frameworks to find out what might work better for teaching programming, with scant rigorous evaluation. For example, we know teaching syntax can be tricky, so a few researchers study better ways to teach syntax while others — like the Scratch team or our team — just try to build new tools that eliminate syntax as a consideration. It’s a tough field in which to stand still and take stock. But Fincher is right that it is very important to properly evaluate teaching approaches and tools.
I know that when I tell teachers I am a computing education researcher, they are usually interested in what research has to say, and often have very sensible questions: What language should I teach in? What order should I cover the concepts? Is blocks-based programming good for students long-term? How should you best manage the transition between blocks and text? Some of these are at least partly personal preference, but we have so little research on them that I am rarely able to give a good answer. The true answer is usually: no-one really knows, and my work makes it harder by trying to build new tools instead of evaluating existing tools.
Although it’s not just the educational part of computing that lacks these answers: a teacher may ask whether static or dynamic languages are best for teaching, while a professional developer may have the exact same question for professional use, and the research there is almost as bare.
I remember during my PhD, where I was creating new abstractions/libraries for concurrent programming, a researcher from another discipline asked how I would evaluate the new abstraction: would I get a bunch of programmers together and get some of them programming with an existing library, and some with mine and see who performed better according to some metric? I remember scoffing, and thinking: no-one does that. But now I realise that is a large problem with the study of programming. Similar to economists, many computer scientists are so convinced that our discipline is purely theoretical and abstract, that we forget that a good part of the discipline is distinctly anthropological. How can we study the programming of machines with so little consideration for the role of the programmer? Educationally and professionally, why do we build so many programming tools and languages without ever stopping to ask: do they actually help?