Teach our kids to code? No, first teach them how to think

My talk at re:publica 2017

On 10 May, 2017, I held a talk at re:publica 2017 with this title. This article is a written version of that presentation’s message.

I want to make a case to those of you interested in IT education: the current movement to teach programming to school-aged children (usually called “Teach Kids to Code”) needs some work.

I think that teaching children how to code is a noble and well-intentioned goal. It’s important that our kids are technologically literate and well-prepared for the increasingly digital future.

But I also think that something is missing from Teach Kids to Code (let’s call it TKTC from now on). Unless that absence is addressed, I fear that TKTC will not achieve an awful lot for most children.

It seems I’m not alone, and I’ll be quoting several people who are making the same case as me.

The Story So Far…

First, a very brief history lesson. This section presents a whistle-stop tour of past efforts at teaching computing in schools. (Disclaimer: It’s probably UK and US-centric.)

The Turtle

© Zhang Weiwu, CC BY-SA 4.0

Among the earliest efforts at teaching computing skills to schoolchildren was the famous ‘Turtle’. In this approach, pupils used a simplified programming environment to control a robot turtle (either real or virtual one) containing a pen in its underbelly. Control was exercised by giving the turtle movement commands using the Logo programming language. Students could learn to write programs that caused complex shapes to appear and, in the process, learn how to program something.

The approach was pioneered by the late Seymour Papert. He hoped that his approach would help pupils become “apprentice epistemologists.” Following their training, they would take their programming skills and learn to apply them in different contexts. It would be a life skill that Papert sometimes called “procedural thinking.”

Unfortunately, it didn’t quite work out like that. Research into the desired outcomes of teaching Logo was decidedly mixed, concluding that children emerged with little in the way of transferable skills.


Fast forward to the 1990s. Just as I entered the education system, Logo was on its way out. I saw my school’s few remaining BBC Micros, along with their Turtle environments, shipped off to Silicon Heaven and replaced with beige Windows PCs. I had arrived just in time to experience the new approach: teaching applications.

Throughout my time at secondary school, I didn’t write a single line of code (not at school anyhow). Instead, my IT teachers taught me how to construct Access Databases, integrate them via mail merge into Word, and things like that. A little later, in the early 2000s, I took my ECDL examinations.

(ECDL stands for European Computer Driving License. It certified me competent in using Microsoft’s products. Lucky me.) [1]

While knowing spreadsheets and word processors is important in today’s computer-intensive environment, it has to be conceded that an IT education like this made children passive users of technology (not to mention dependent on the world’s wealthiest technology companies).

Teach kids to code

This brings us to today. We’ve now concluded children shouldn’t be passive users of computers. They should instead become active, empowered controllers of technology. We should teach them how to write code.

Today we do things like teach them Python, a relatively friendly programming language. We give them snazzy, colourful environments like Scratch! where they can intuitively snap together blocks of code.

The criticisms

Much has been written on TKTC. A fair amount I’ve seen follows a similar pattern: praising the noble intention, calling it a step in the right direction, but criticising it for missing something important. Let me cite a few of my favourites.

Code isn’t the best ‘universal language’

Kipp Bradford, a Senior Research Scientist at MIT Media Lab, pointed out that the programming landscape is complex. Hundreds of programming languages exist in all shapes, sizes, complexity and paradigms. Simply teaching someone to code means having to choose one and use it as the means of instruction.

But, despite the job title, professional coders rarely think in terms of code. Code is the end product. It’s what we use to put our ideas into a form a computer can understand after we’ve worked them out. Interestingly, coding languages — for all the endless variety of languages, platforms and paradigms — share a relatively small number of core concepts.

It’s important to realise that writing a computer program does not equate to writing code. The complete process of writing a program includes a whole lot of activity prior to writing code, in particular understanding the problem, breaking it down, and working out a solution that’s correct and acceptable [2]. Writing code follows all this work and takes up a minority of effort.

Who is really benefiting from this?

So why does all the work prior to writing code so often go missing from TKTC?

Amil Dash, CEO of Fog Creek Software, argues that TKTC is often driven by policy makers and industry figures who are to some extent ignorant of technological issues. Code is all they know, so it’s easier to push the “Johnny needs to learn how to write code” message. They don’t realise that “coding” (meaning software development) is actually less to do with writing code than it is to do with problem solving.

Dash goes on to say that some people do benefit from TKTC, but it’s not necessarily the people you might expect. He warns that simply teaching coding risks producing an assembly line of code monkeys for some of the wealthiest, most powerful companies on Earth, all funded by you the taxpayer.

Great for them, not so beneficial for our kids and society.

We’re doing the ‘pop’ version of coding

What it comes down to is that teaching the tool is easy. Teaching the skills to use it well is hard.

Idit Haril, also (formerly) of the MIT Media Lab and a former collaborator of Papert’s, criticised some aspects of TKTC, in particular the simple coding apps used in US schools. Her view is that the current approach is a “superficial response to the increased need for coders”, a sort of “pop computing” that imparts no deep skill to the student.

Atilla Vágó, a software developer and writer, also decries that programming has become pop culture, which underestimates how hard it is — although the hard part isn’t learning to code. The hard part is teaching an analytical, problem-solving mindset.

To use a metaphor inspired by Vágó: if I learn musical notation, which anyone can do in a few lessons, does that mean I can then compose my own music or even begin to understand how music really works?

A pattern emerges: Computational Thinking

As you read the critics of TKTC, you observe a pattern. Yes, many say, teaching kids to code is a worthy, noble goal, but we’re also avoiding the deeper issue: we need a way to connect the coding and the problem solving, something that imparts the deep skills behind the tool.

That something is often as referred to as ‘computational thinking’.


Computational thinking is an approach to problem solving that uses key ideas from computer science for formulating solutions executed by a computer.

Key ideas

The basic components of computational thinking break down into five categories.

Logic and algorithms: The nuts and bolts of any computer-based solution. They tell us how computer brains work and thus what kinds of instructions we can give to a computer. Learning logic and algorithms teaches us the correct way to communicate with a computer, because we can’t use human-style communication.

Problem decomposition: A large problem is hard to solve in one fell swoop. This can overwhelm and discourage you. The key to solving one is to break it down into a set of smaller sub-problems. Perhaps some of the those sub-problems are also too big to solve, so they should be broken down into sub-sub-problems, and so on. Eventually you have a kind of hierarchy where the simple problems at the lowest level indicate a set of tasks you need to carry out to solve the original large problem.

Pattern recognition: Finding patterns in a problem makes problem solving easier. When you find patterns among a problem, you simplify the eventual solution. You can use the same problem-solving approach on each occurrence of a pattern instead of re-inventing the wheel every time.

Generalisation and abstraction: Pattern recognition leads to generalisation. By picking out the relevant patterns, you learn which details are irrelevant to your solution. Focusing on the relevant patterns allows you to build up a model of the objects in your problem (a.k.a. abstractions) which only contain the necessary detail. Unnecessary detail gets left out, making the solution both easier to solve and also applicable to other other similar situations.

Solution evaluation: Once you’ve built a solution, you have to be able to evaluate it and decide whether it’s acceptable. Does it actually solve the original problem? Does it perform acceptably? Is it secure? Is it easy to use?etc. Evaluation skills give you the questions you need to ask and the means to answer them.


At this point in the talk, I gave some examples to help illustrate some key ideas.

Algorithms: Peanut butter & jam sandwiches

My favourite way to impress upon beginners the communication style needed to instruct a computer is to play the peanut butter & jam sandwich game.

You (the teacher) play the role of a martian. You can understand English, but you have no notion of human social norms, figurative speech or common sense. You understand statements in a literal, almost robotic way. Before you is a loaf of bread, a jar of jam, a jar of peanut butter, a knife and a plate.

The students’ task is to write out instructions for making a peanut butter & jam sandwich.

After they give you their attempts, you take the instructions and follow them… pedantically and literally!

A first attempt might look like this:

  1. Open the bread
  2. Take it out
  3. Put the peanut butter on the bread
  4. Put the jam on the bread

At which point, you get to have fun by reading out each step and performing it.

“Open the bread.” You proceed to rip apart the loaf.

“Put the peanut putter on the bread.” You place the jar of peanut butter on the load of bread.

And so on.

Once crumbs and blobs of jam cover the desk, you can begin to teach the students about the need for instructions to be precise and unambiguous. The students might take those lessons and produce a second improved version:

  1. Open the bread packet
  2. Remove 1 slice of bread from the packet and place it on the plate
  3. Open the jar marked “peanut butter”
  4. Take the knife and use it to scoop up approximately 10 grams of peanut butter
  5. Spread the butter onto one side of the slice of bread

This also serves as a lesson that solutions should be sought iteratively. Your first attempt will likely be wrong in some way, and that’s totally fine.

Decomposition and pattern recognition: Smiley faces

Drawing images provides a nice way to get across the lessons of decomposition and pattern recognition. Instructing a computer to draw a complex image is a multi-step process, so it can’t be solved in one go. However, by decomposing an image into a series of simple shapes, you break the problem up into a series of simple sub-problems that can be solved individually.

As a simple example: a smiley face. It’s one image, but it actually contains several component shapes:

  • A large circle for the face.
  • A medium circle for the outer eye.
  • A small, filled circle for the inner eye.
  • An arc for the smile.

Pattern recognition shows that the individual components of a complex image can actually be reduced down to just two types of shape, albeit ones with varying properties. For example:

The student can then build on that solution and apply it, with minimal adjustment, to drawing other similar images:

  • A sad face
  • A bemused face
  • A face that looks suspiciously like a copyrighted character

And that’s just smiley faces. If you apply that same approach to other images, just imagine that complexity that can be built up.

Just imagine…

And, given the limited time I have in this presentation, that’s what I’m asking you to do: take what I’ve told you, learn more about computational thinking, and imagine.

Imagine our children armed with a predictable, repeatable problem-solving technique that enables them:

  • … to learn how to think of problems in general, abstract terms
  • … to be able to turn those ideas into instructions a computer can understand
  • … to realise that a key part of handling problems is to break them down into solveable pieces rather than be overwhelmed by complexity.

Once they have created a solution, it will be ready to be plugged into computer technology and executed automatically.

They’ll have a plug-and-play, problem-solving toolbox for the 21st century.

Final thought

“Pick any field X, from archaeology to zoology. There either is now a ‘computational X’ or there soon will be.”
— Stephen Wolfram, How to Teach Computational Thinking

Notes and references

[1]: Interestingly, when I asked my audience of over 100 people (presumably majority European) who had heard of the ECDL, I didn’t see a single hand go up!

[2]: Or, more likely, working out many possible solutions and then choosing the right one