Finland has gone gaga for coding. The new Finnish curriculum requires that coding needs to be taught from preschool up. Nathan Holland imagines what teaching coding to five-year-olds might look like.
Trousers and Mandates
Earlier this week I was attending a preschool parent meeting. Top of the agenda was an outline of all the various mandatory accessories the children required. In Finland it seems to be very important that children are wearing the exact right type trousers/coat/hat/gloves/shoes for each day of the year. If you are Finnish, you probably think I am being facetious, if you are not, you probably think I am over exaggerating. Let me give an example: At this parent meeting I had with me two pairs of outdoor trousers to go over the top of my son’s normal trousers, my partner had asked me to bring “the outdoor trousers” and since I didn’t know which she wanted I brought both. Upon presenting my wares I was met with a shake of the head as I was informed that neither would do and it was in fact a third pair still somewhere at home that were the only acceptable secondary trousers for early September forest excursions. I’m getting off track.
Next on the docket was a brief overview of the children’s daily routine and then on to the inspiration for this article. An edict had come down from the powers that be announcing that all children in Finland would learn coding. So our five-year-olds would this year be introduced to the world of software design, albeit not in the context of any computers. As none of the teachers had any computer programing experience, the exact form that this introduction would take was as yet undetermined. As a professional software developer, former teacher and zookeeper parent to a five-year-old I thought I should be able to devise a solution. And so I set about planning out how to teach coding to kids. Without a computer.
Stepping into a classroom and announcing to the assembled preschoolers that we would be building pong
I decided that my hypothetical class of five-year-olds and I would build a game. It had to be something simple enough that children could grasp all the logic behind the game whilst being engaging enough to hold their attention. The game that sprung into my head was pong, so that is what we will build. Imagining stepping into a classroom and announcing to the assembled preschoolers that we would be building pong, I realised that my next task would probably be explaining to people born in the 2010’s what pong is. Since my class is imaginary I will wheel in an original 1970s Atari arcade version to show the kids. For real world convenience there are loads of free apps replicating the game: https://play.google.com/store/apps/details?id=com.codamasters.pong – this one is a real stickler to the original blueprint. Now that the class is familiar with the game and how it works we can start coding.
“What can you tell me about this thing.” I point to the ball on my arcade machine. Picking a random hand from the sea of raised wiggling fingers I receive the answer.
“It’s a ball”.
“Brilliant, what else do we know about it?”
Silence. A bit of directional prodding seems to be needed.
“Can anyone tell me what colour the ball is?” All hands go up again.
“And where is it?”
This time only a few hands go up.
“In the middle.”
“Is it always in the middle?” – shaking heads.
“Is it always white?” – nodding heads.
So we have this thing, this object and we have given it the auspicious name of “ball”. We can define our ball by saying all the things that we know about it. Some things are constant, like its shape, size and colour, but others, like its position, are not. At this point I would take a volunteer to be the ball. This child is only allowed to act according to the programming we give so that we can test our code later.
Next we tackle our second object: paddle. Like the ball we know its shape: a rectangle, its colour, white, and its size. So these are our constants (final variables to give the technical jargon) for the paddle. Its position like the ball varies but there is a difference. The ball can be anywhere but the paddle is always on the left, only moving up and down. This bit is probably a stretch for five-year-olds but we can explore it here. The game is in two dimensions so we use two variables to describe position. Essentially an x and y coordinate. In the case of our paddle object we have a fixed or final x value and a changeable y value. Since the only difference between the two paddles is the value of that x coordinate we can code a paddle object and then simply create two instances of it, one with an x value to put it on the left of screen, the other on the right. This is the hinge on which object oriented programming rests. We build generic objects that are initiated with a particular set of values to fit the purpose we want to use them for. The next feature of our paddle object is the ability to move up and down based on a user input. The input options will be simply up and down, each input results in the child in the role of paddle taking one step up or down (an increase/decrease in the y coordinate value).
We are almost ready to test our game for the first time. We just need to give a bit more information to the ball about how it moves. We tell the ball that it keeps moving in a straight line until it touches a paddle at which point it should bounce off. If we imagine a ball bouncing we know intuitively which way it will bounce off. We know if we throw a ball against a wall at an angle that it won’t come back to us, instead it will rebound at the same angle on the other side. In the case of a computer we need to program some basic trigonometry to calculate this.
Off on a Tangent
On reading this back I realise that we actually don’t need any trig calculations, this paragraph is a bit off topic so if you aren’t too interested in the underlying maths then skip ahead to our alpha testing. If we imagine a real world ball bouncing there are several things to consider such as the effect of air on the ball’s flight or the energy that gets converted into sound and heat at the point of impact. In a simulation we can ignore all these things and assume a perfectly elastic impact, however we consider the geometry. We would take the component of the ball’s initial velocity that is perpendicular to the wall or paddle and multiply it by -1, leaving the parallel component the same. This would give us the new velocity of the ball after impact. In the case of our game the wall and paddle are always along an axis so the x and y values for the ball’s velocity are already parallel and perpendicular. This means we need only multiply the x or y component by -1 to get the post bounce velocity, avoiding the need for any trigonometry. In modern computers these types of calculations wouldn’t strain the system at all but on 1970s hardware this would have saved valuable resources. At the forefront, coding efficiency is always paramount, even if you’re not pushing the limits of the system it’s important not to slow other processes or to eat up a devices battery life by having your code run superfluous operations. Now we can get back to our classroom.
Now we are ready to test our game. We choose two paddles along with our earlier volunteer for the ball. We select to players to provide the inputs to each paddle.
I ask if everyone is ready and say “GO”. What will happen at this point is a toss-up between chaotic running around and shouting of up and down or blank looks as everyone is unsure what to do. All our objects are ready but we need something to organise them, to put them where they should be. So this time I take the first paddle and place him or her on the left, I tell him or her that they can’t move up or down beyond a certain point that I mark for them. They already know to move up when they hear the command “up” from their player but now they are subject to the constraints of the system. I do the same with the second paddle but on the right. In technical terms I have assigned the final variables to those objects. Now I take the ball to the middle and tell him or her that as well as bouncing off the paddles they will bounce of the walls which I mark out. I also tell them which direction they should move in when I say “go”, I have assigned the initial variables for this object. This time around when I say “go” the game should work as planned. Hopefully.
What will happen at this point is a toss-up between chaotic running around and shouting of up and down or blank looks as everyone is unsure what to do
Object oriented programming works by creating objects and then putting them into a system where they can interact with the system and each other. In the case of pong this systems aims to simulate a simplified game of table tennis. This system to which all the objects belong is called a class and the objects in it are the children of that class. I hope that this etymological overlap is enough justification for overlooking any holes in my analogy of programming but I think it works quite well.
At the end of my thought experiment I am convinced that teaching the principles of software development to five-year-olds is entirely feasible. I can understand why a government think tank of civil servants with no experience of coding or teaching would want to start this initiative – we are all constantly hearing that computers are the future. I can also see genuine benefits for the kids learning it: problem solving skills and an awareness of how all the computer devices in their lives work. But in my mind I can’t help but think that kids really don’t need to learn this stuff for two main reasons: all the general problems solving skills that are useful outside of computer programming can be gained by studying maths. If kids get to 18 able to do trig and factorise quadratics and solve differential equations, they will have no problem learning to code if they decide that’s what they want to do. They will also be suitably prepared to become physicists or lawyers or doctors. And if we were to assume that the future doesn’t need lawyers and doctors, all we need is people building computer programs it’s not just coders you need. Modern software design teams comprise Graphic designers, UX designers, Testers, Marketers all working alongside coders. I’m assembling a team for an upcoming project at the moment and every capable graphic designer I have reached out to is busy. If we really need to prepare kids to work in software development these three things will suffice: teaching them how to use computers, encouraging their creativity and teaching them maths.