170 research papers about teaching programming, summarised

Computer programming is now part of the school curriculum in England and many other countries. Although not necessarily the primary focus of the computing curriculum, programming can be the area teachers find most challenging to teach. There is much evidence emerging from research on how to teach programming, particularly from projects with undergraduate learners. That’s why I recently wrote a report summarising over 170 programming pedagogy papers: Teaching programming in schools: A review of approaches and strategies.

In a computing classroom, a smiling girl raises her hand.

I hope this blog post about how I approached writing the report whets your appetite to read it, and encourages you to read more research summaries in general.

My approach to summarising research papers

Summarising findings from more than 170 research papers into 34 pages was not a task for the faint-hearted. I could not have embarked on this task without previous experience of writing similar, smaller reviews; working on a host of research projects; and writing reports about research for many different audiences.

A computing teacher and a learner do physical computing in the primary school classroom.

I love reading about computer science education. It evokes very strong emotions, making me by turns happy, curious, impressed, alarmed, and even cross. When I summarise the papers of other researchers, I am very careful when deciding what to include and what to leave out, in order to do the researchers’ work justice while not overselling it or misleading readers. Sometimes research papers can be hard to fathom, with lots of jargon and statistics. In other papers, the conclusions drawn have many limitations: the project the paper describes hasn’t produced robust enough evidence to give a clear, generalisable message. Academic integrity and not misrepresenting the work of others is paramount. And naturally, there are many more than 170 papers about teaching programming, but I had to stop somewhere. All this makes summarising research a tricky task that one has to undertake with great care.

a teenage boy does coding during a computer science lesson.

Another important aspect of summarising research is how to group papers. A long list saying “this paper said this”, “this paper said that” would not be easy to access and would not draw out overall themes. Often research studies span many topics. What might be a helpful grouping for one reader might not be interesting for another.

For this report, I grouped papers into three sections:

  1. Classroom strategies: Here I included well-researched classroom strategies that teachers can use to teach programming in schools
  2. Contexts and environments for learning programming: Here I outlined research related to opportunities for teaching programming, including different programming languages and the classroom context
  3. Supporting learners: Here I summarised research that helps teachers support learners, particularly learners who have difficulties with programming

Why you as a teacher should read research summaries

Teachers, as very busy professionals, have little time to replan lessons, and programming lessons are challenging to start with. However, the potential long-term benefit may outweigh the short-term cost when it comes to reading research summaries: new insights from firmly grounded research can improve your teaching and enable more of your learners to be successful.

In a computing classroom, a girl laughs at what she sees on the screen.

The process of translating research into practice is an area that I and the research team here are particularly interested in investigating. We are looking forward to working with teachers to explore this.

The Raspberry Pi Foundation regularly shares research summaries in the form of:

You can also check out other computing education podcasts e.g. CSEdPod.org, as well as computing education books (e.g. The Cambridge Handbook of Computing Education Research,  Computer Science Education: Perspectives on Teaching and Learning, and many others), and other researchers’ blogs about computing education (e.g. Amy Ko, article summaries on CSEdresearch.org).

Jump to the comment form


As someone who has been actively involved in teaching coding, to a wide variety of non-traditional learners of programming, including bootcamps of my own foundation, teaching coding to low-opportunity youth in S.E. Asia, as well as in the US and Canada; as someone who is currently involved in the development of a game-creation tech-skills program in Cambodia – my own initiative, and working with the IT Association for this country; and as someone who has decades of experience as a lead developer, as founder of several tech startups – I read this report and can only marvel of its completely useless nature.
You are asking none of the questions that need to be asked, and accepting terrible assumptions to start with. I am very familiar with how the anxieties of the IT industry manifest themselves, as it still finds itself in a weak bargaining position vis-a-vis coding, a crucial form of unobtanium that entirely breaks the assumption of asymmetrical leverage held by corporations over workers, after decades of expectation that a manufactured glut of programmers would restore the preferred balance.
This anxiety always manages to manifest itself in the minds and words of those whose imagination of the professionalization of education creates exactly the methods and obstacles to effective code-learning. The agreement around who should learn to code, what coding is, and indeed the essential nature of coding is summarized in your statement regarding teaching techniques: “you use many teaching techniques, and their application in teaching coding is unproblematic.” [paraphrasing].
No, you are wrong. it’s entirely problematic, and what you are laying out is a first step for legions whose skills will never rise to the level of market leverage: at best, you’re focused on developing the skills that managers of those who code employ: a cursory understanding, an inflated sense of capability, and a disregard for what makes coding what it is, in the current stage of technical development. This has been tried, so many times, and there were other ineffective attempts to survey and reduce the fundamentally problematic nature of coding by similarly academically constrained writers. They failed, as is witnessed by the continued economically distinct position of the coder: considered an engineer, but with no need whatever for certification: only the ability to execute, and to realize and express the abstractions of large social, economic and financial movements, before they’re described elsewhere. Like all translations, these are only valuable in their nuance, not their literalness, and what you describe is a world of code without nuance: in other words, a waste.

Reply to Daniel Donaldson

Jane Waite

Many thanks for your response to our blog about the programming pedagogy report.
As a developer who worked in industry, in banks, and in other large institutions for 20 years, before becoming a teacher and then a researcher, I personally very much understand your frustration with the issue of how we create a pipeline of effective developers.

It’s great to hear that you are so actively involved in addressing this issue with all your work on teaching programming.

The pedagogy report is a synthesis of research in the field of computer science education and this research is still developing.

Teaching programming is hard. The research in the field provides some ideas about how to help educators make it less hard. But we still have much research to do and we are investing much time and effort in supporting this through our work at the Raspberry Pi Computing Education Research Centre.

Reply to Jane Waite

Leave a Comment