Guest article by Derek Blunt.
Just because everyone says something is good, doesn't mean it is.
One of the biggest growth areas in educational Computing at the moment is what may broadly be called “making”. Whether it’s constructing objects using Lego bricks, experimenting with the BBC Micro:bit or experimenting with an Arduino, the so-called “Maker Movement” has now entered the classroom.
But does it actually work? And by “work”, I mean: does constructing a robot or making a bulb light up on an Arduino board help students to learn coding? If the answer to that question is “yes”, then the next question has to be: do the benefits of making, in terms of its impact on learning to code, outweigh the costs?
So what might be the theoretical basis for learning to code through making? The obvious answer would be to cite Piaget’s Concrete Operational Stage of learning. This is the proposition that at a certain stage of development, children can understand and apply logic, but only to physical objects rather than in abstract thinking.
But building a crane or a robot or connecting up a glorified circuit board is the concrete operational stage of construction, engineering and electronics respectively, not coding. If you want a concrete object for coding, you don’t have to look far. It’s called a Roamer or a Beebot. Unfortunately, they look too childish to appeal to teenagers, but there are almost-concrete alternatives, like LOGO, Scratch and Flowol.
What does the research say?
Good question. Searches turned up no hard data whatsoever. There seems to be no academic research which reports that as a result of “making”, pupils have learnt to code, much less learnt to code more quickly or better. The closest any reports come to stating anything remotely tangible is that "making" is potentially a way of getting them interested in STEM subjects.
What the research does say is that the kind of step-by-step instructional activity that seems to accompany making in classrooms is really not what the maker movement is all about. They emphasise bricolage (OU Innovating Pedagogy 2014 [1]) and tinkering (MIT[2]). These terms denote experimenting, seeing what happens, without necessarily even having a concrete goal in mind at the outset — a far cry from the plodding, step-by-step instructions that seem of necessity to be a feature of using kits in the classroom. Indeed, Resnick and Rosenblaum say themselves that one of the biggest challenges is the time it takes to get started on the actual work you wanted to do – in this case, the programming.
That leads us on to the practice. What does a making-for-coding lesson actually look like?
In the mid-90s, I myself, as Head of ICT, bought a maker kit for the purpose of getting my students to things that could then be wired up and programmed from the computer. As soon as I took delivery of the kit I realised that I’d made a very costly mistake. It was obvious that the amount of time and organisation required simply to build a bridge or whatever would be too much. This brings us back to the question of cost.
The main cost is time, which, at an hour a week for the subject, has a premium value.
Another cost is the expense of replacing bits of kit that get lost, stolen or used as catapult fodder.
In the last year I’ve taken part in two workshops, once concerning the Arduino and the other concerning building something with bricks and then programming the result.
In the first, I spent half an hour watching my colleague fiddle with bits of wire, at the end of which process a bulb lit up.
In the second workshop, we were divided into groups of three or four. In my group there was a chap whose job it was to find the next brick or widget for the construction, a lady whose role was to do the building, and myself, whose task was to press an arrow on a screen to show the next step in the instructions. At the end of 25 minutes we had constructed a robot, which the “teacher” then programmed by clicking on an arrow on the screen.
I wonder how an Ofsted inspector with even the most rudimentary knowledge of Computing would regard a lesson in which, arguably, everyone in the class was engaged in a completely irrelevant pursuit for half the lesson.
If you really do want to take advantage of young people’s perceived desire to build things out of bricks or fiddle with wires, there are a number of ways you can do so without wasting lesson time.
● Work with the Design and Technology department (if your school still has one).
● Buy ready-made robots, bridges etc, and get the students programming from the word “go”.
● Start a Bring Your Own Robot scheme.
● Start an after-school Maker club.
Or better still, stop trying to pander to the latest fad, and do something radical. Like teaching computer programming.
Derek Blunt: Blunt by name, blunt by nature
Footnotes
2 Designing for tinkerability, by Resnick and Rosenbaum, in Design, Make, Play: Growing the Next Generation of STEM Innovators edited by Margaret Honey, David E. Kanter