The ability to create, evaluate and improve the inner workings of software at a range of levels of detail is becoming an increasingly valuable skill in the 21st-century workplace. But are we teaching children to code in a way that supports this?
London CLC teaching and learning consultant Rowan Roberts has consulted software industry professionals to come up with a range of practices that can turn a good Scratch programmer into a great one – and she’s turned it all into a brilliant free online short course for Tech Pathways London.
Here we’re offering a flavour of it. It’s in seven parts – read the first couple here, get a taste of parts two to seven and head over to Tech Pathways to enjoy the rest.
Introduction: What makes high quality code?
What makes high quality code? It’s a difficult question, and one that even industry professionals often struggle to answer. When learning to program, particularly informal environments, most of us learn that there are many ways to solve a problem and that, as long as your solution achieves the desired outcome, it’s as valuable as the next person’s. But is this really true?
In the tech industry the vast majority of developers are not working in isolation on discrete problems, but as part of a wider creative team made up of people with different roles, skills and knowledge. They need to be able to understand their part in this process, developing effective means of communicating ideas. They need to create solutions that can be adapted, improved or grown as problems change.
All this might sound like high level stuff, but working in this way would be easier for all of us if we picked up better habits earlier on in our programming careers. Here are some suggestions for practices we can teach children to use when they are programming with visual programming languages like Scratch to support them when they enter the world of text-based coding and eventually, for some of them, the software industry.
1. Make your code efficient and adaptable
Let’s say you want to program a Scratch sprite to count to 10. What would be the first thing you’d do? Maybe you’d simply make a list of blocks, each of which gets it to speak a different number:
You can test this script in this project by pressing the green flag and listening to Robot 1.
As you can see, it solves the problem perfectly well. But is it the best solution?
One way to improve the code would be to make it more efficient. Robot 1 uses ten different “Speak” blocks to count. This is not a very efficient piece of code, since although the blocks aren’t identical the instructions are pretty repetitive. Perhaps we could use a repeat block? But we can’t just repeat the same instruction, as our robot needs to say a different number each time it speaks.
This means we need a variable. In programming, a variable is like a label or name which can act as a number in your program, except that the value of this number can change. When you count you can think of the number you say each time you speak as a variable. Each time you speak it gets one bigger. Other common examples of variables are scores, health or timers in games.
In Scratch there is a “Variables” section in the block library. Here you can make your own variable and call it whatever you like; I did this for Robot 2 and called my variable ‘currentnumber’. This script I used is below:
As you can see it’s much more compact, and uses far fewer blocks than the previous script. And as long as the problem is limited to counting in ones it’s perfectly serviceable. If you needed to adjust it so that it only counted to five, or went all the way to 100, you could easily just change the repeat number.
But what if you wanted it to count up in 10s insteads of ones? Or what if you wanted to use the script to recite the 7 times tables?
In the software industry developers are constantly implementing ideas with half an eye on how they might need to change in the future. At the moment the script above can be adapted to, for example, recite the 9 times tables, but in order to do so it would be necessary to change both the increment that the variable changes by (‘change currentnumber by_’), and the starting number (‘set currentnumber to_”), to 9. These changes might seem small, but when a piece of code is just one part of a much more complicated project, the time taken to complete them adds up and creates more opportunities for human error.
For this reason, Robot 3 invites you to build your own version of this script. This time, though, the robot should ask the user which times table they’d like to hear, then recite it. When you run an “Ask” command in Scratch and enter an answer, whatever you type is stored as a variable in the small blue “Answer” block. This answer can then be used in your code; so if your answer is 7, you can make the robot count in 7s. But if you answer is different next time you answer the question your robot can tell you a different times table. Try building the script this yourself or use the example below to guide you, by clicking “See inside”, choosing Robot 3 and defining “COUNT(3)”.
This solution achieved something slightly different to the original script, but if you answer “1” the counting part looks exactly the same. It is, however, a much more efficient and adaptable piece of code, giving it the potential to be far more useful.
Enjoyed the first part of the course? Here’s a favour of the rest:
2. Make use of methods and procedures: use ‘More Blocks’
If you’re collaborating on any piece of work with a colleague, it’s important that they can read and understand it. This applies just as much to code as it would to a natural language, but a common habit among the keenest of young Scratchers is to relish building the longest and most logically complex scripts they can manage. While it can be fun to challenge ourselves in this way it can make it near impossible to explain how our code works to someone else, and can even mean that, if we haven’t seen it in a while, we can forget how it works. Not to mention the fact that if something in our code isn’t working properly it’s a lot harder to fix.
3. Test your projects thoroughly
You might not necessarily think of testing as being part of the process of actually coding, but it’s pretty fundamental at any level, and particularly so in the software industry.
Let’s take an example; can you test this project? Start by clicking “See inside”. What do you think will happen when you run the code? Test it out by clicking the green flag. Does it do what you expected?
If it does… you probably haven’t tested it properly! To test this program fully you need to know what happens when you get the answers wrong as well as right.
4. Organise your code
As we saw in the last activity, it can be really confusing when the assets (sprites, costume, sounds etc) in your project are not named in a way that describes what they do or makes them easy to identify. The Scratch team have actually made this easier in Scratch 3 by automatically naming any new Sprite something that relates to its appearance if you choose it from the costume library, but if you draw your own you’ll still find it automatically named “Sprite1”, “Sprite2” etc.
5. Use the comment function
Many of the suggestions I’ve made so far have been to do with making code as easy as possible to understand. But there’s an even more straightforward way to achieve this; simply explaining it.
By right-clicking on any block in your Scratch script area you can attach a comment to it. This can be useful for all sorts of reasons. As a teacher it can be a way to ask your pupils to demonstrate understanding by annotating their code. You can sometimes use it to deliver instructions within a project like this one, which talks you through the process of creating a Maya calendar. You can also use comments to provide further explanation, as in this Egyptian hieroglyphs project. This can be useful for differentiating activities or supporting independent work.
6. Conclusion and next steps
I have focused here on defining quality in code, but it’s also helpful to be aware of some of the pitfalls of poor quality code, known in the industry as “code smell”. Quality for blocks has some great explanations of what code smell is, what it looks like in Scratch, and how you and your pupils can avoid it.
I hope some of the example projects used above might give you some ideas for activities you could use with children, but as well as considering what we teach students it’s also important to think about how we are teaching it.
For evidence-informed ideas on how to structure programming activities I highly recommend anything published by KCL computer science education department, and in particular an approach called PRIMM. It’s a way of structuring coding activities by moving through five steps: predict, run, investigate, modify, make. Using this basic structure you can often create a really engaging activity simply by finding a progression-appropriate example project on the Scratch website, or making one yourself.
You are also welcome to browse my own Scratch page which contains lots of the projects I’ve used with pupils over the years, the more recent of which tend to include instructions or notes to help support their use with pupils. If you give any of them a try I’d love to hear your feedback in the comments.
- Sign up to our weekly newsletter to get edtech news and views, free resources and reviews direct to your inbox every Thursday lunchtime – including a weekly ‘give it a try’ app or tool recommendation.