The holes in computing education research

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?

2 thoughts on “The holes in computing education research

  1. That’s an excellent post, thanks for the reading and for the food for thought. It is a pity indeed that there is not particular philosophy and pedagogical recommendations on how to properly teach computer science. I’ve been struggling with the idea of writing a teaching philosophy statement, just because my perception of how things should be taught is not backed up by any research. Hopefully we’ll start seeing changes soon, before we have wasted years experimenting and failing to educate students with diverse backgrounds and abilities.

  2. “why do we build so many programming tools and languages without ever stopping to ask: do they actually help?”

    it gets worse. if you make something that actually helps, you will have to prove it to people armed with nothing but preferences and prejudices. there is no way to prove their prejudices to be unrealistic. its all a matter of opinion.

    to answer your question, i created a programming language to help me teach non-coders, because i was having too much trouble teaching python (even though its very good for the job) and i spent enough years trying to find the “right basic.” (spoiler alert: its python.)

    so i took note of the problems i ran into, and made a language with the best of python and basic, without the problems. is it helping me teach? yes! but now i have to prove its a useful language, against the sort of thinking that “if its not the best for X, its no good.”

    instead, i intend to just keep using it for its intended purpose. but its also research: im constantly trying to figure out how to reach more people. if theyre learning python, i help them with python. if theyre happy with scratch, wonderful. i dont use blocks much, because i still havent found a blocks language with the features i want. i will look into frames also.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s