As I mentioned in a recent blog post about apps for programming, we are rather spoilt for choice in the number of learn-to-code tools that are available today. Whatever your available platform, you are likely to be able to find a range of on and offline tools for teaching children the basics of programming. Some of these guide the user, step-by-step, through a learning journey, others are blank canvasses (often accompanied by tutorials) and some are combinations of both.
How can we make sure that children get the most from these tools and develop an understanding, through their use, of the key computer science / programming concepts that the national curriculum outlines?
I feel that without structuring and focusing their use, sometimes using these tools can lead children towards being competent users, often experts, of that particular tool without really understanding the concepts they are applying through their programming.
So, in no particular order, let’s have a look at some of the things we can do with programming tools, in addition to ‘just’ writing programs, to get the most from them and maximise that computational thinking and learning!
Start unplugged
Yet again he found his underpants on the outside!
I’m a firm believer that the programming concepts/principles are best introduced and taught away from computers. Let’s start by concentrating on what the concept is, rather than how it’s done in a particular tool. A variable can be a cardboard box into which counters are dropped for each correct answer in a quiz. Selection can start with a bag full of coloured bricks, which need to be sorted. And we all know what happens when a certain super-hero gets his sequence wrong when getting changed in the morning. Once the concepts have been taught unplugged, and practised through creating algorithms, they can be moved to a programming tool and the children taught how they can be applied in that tool, through simple examples that exemplify the particular concept(s). I think that by having been through the process of learning a concept away from a computer, it is much easier for pupils to understand how it works within the chosen programming tool.
Tinker and explore
Yes, I’m still advocating time to simply play within the programming environment. There is so much to be learned from exploring, trying out, and asking the question, “What happens if I do this?” But if this is where the use of the tools starts and stops, that’s when the deeper understanding might be missed. So do allow ‘free play’ time – most of us, in fact, learned much of what we know about the programming tools themselves from doing exactly this.
Copy and change existing code
Rather than starting from scratch (no pun intended) you can provide ready-prepared programs for children to change, just to see what happens or to achieve a particular objective. Some learn-to-program tools work in this way. The step-by-step activities in Code Monkey [ http://www.playcodemonkey.com/ ] have children changing and debugging lines of given code to achieve the goal of the activity.
Of course, you don’t have to rely on tools that have this built-in, you can provide your own programs for children to copy and change, or you could download other people’s code if the tool has an online gallery (providing the terms of the service allow you to do this, of course.)
I think copy/change is particularly valuable when introducing children to how the programming concepts that you may have taught unplugged, are applied in a particular programming tool. E.g. moving from a variable being a cardboard box to a variable being created/named and used in Scratch or Logo.
Predict what will happen
Again, here we are providing the children with code (or code-blocks if that’s the sort of tool you are using) but rather than changing it, we are asking them to look at it and predict what will happen when it is run. So this can be done away from the computer – project some code onto the board, provide print-outs or screenshots, or get the children to share their own code with a learning partner and predict the outcomes of each other’s work. With younger children, this ‘code’ may be a sequence of arrows for getting around a map. Where would the robot end up if it followed these instructions? With older learners you may wish to focus on a particular programming area in these activities, such as variables, selection, procedures etc.
Debug
I’m trying to draw a pattern but something is wrong with my program
As soon as children start creating instructions, they will need to start debugging, in order to find and correct their own mistakes and make their instructions more accurate and efficient. And of course this continues when they start to write their own code (or use blocks.) But we can make debugging the focus of an activity by providing code to the children that has ready-made mistakes. Can they find and correct them? As above, this activity can be started away from the computer, and is likely to be more challenging when the pupil is having to find the mistake by reading the code rather than running it. So prediction is involved here, as well. You could ask the children to write their own program (on paper, or through a programming tool) with a deliberate mistake and see if their learning partner can find and fix the mistake.
This could be as simple as a wrong turn for a floor robot or more advanced, such as a syntax error in Logo.
I want to draw a square. Where have I gone wrong?
Explaining what you’ve done
Scratch has an ‘add comment’ feature
And really important, in ascertaining the children’s understanding of the programming concepts they have used, is asking pupils to explain what they have done throughout their programs. Can they show where they have used selection, for example, and what the effect of this is? Scratch in particular has an often overlooked feature where a comment can be left next to the blocks of code used in a program. Simply right-click in the scripts area and choose “add comment.” So ask children to label their program to show their understanding behind the code they have produced. Or, if working with younger children and physical programmable floor robots, ask them to tell you what each button press will do as they enter them.
I don’t wish to devalue the activities and projects which children should undertake, where they design and write a program from scratch, to a particular specification. This often takes the form of creating a game or screensaver. This is, of course, an important part of the work the children will do in computing, and what I have described above can be part of the journey towards these projects or a complement to them. By using programming tools for a variety of activities and foci, in addition to ‘just’ writing programs, we can, I believe, get more from the tools in helping children apply different skills and problem solving approaches, and deepen their understanding of the key programming principles they are using.
Chris Carter
