The biggest hurdle in introducing programming to young children are computers. Indeed, with all their bells and whistles, modern computers are a constant distraction for young children, or more generally for new users. Where to look, what to focus on? I think this is even more acute since now every child is accustomed to using tablets, and their experience of using ‘computers’ is very much driven by intuitive interfaces and instant gratification. Typing abstract keywords on a keyboard is certainly not an inviting experience.
Scratch is a graphical programming language, that provides visual abstractions to programming concepts such as simple instructions, interaction, conditions,… Scratch programs are created by drag and dropping these visual elements to create programmes that control a cat on the screen.
With Scratch, you can program your own interactive stories, games, and animations - and share your creations with others in the online community.
Scratch helps young people learn to think creatively, reason systematically, and work collaboratively - essential skills for life in the 21st century.
From my personal experience with my older son (now 9), even getting him interested in Scratch is a bit challenging. While the why and how of all these visual elements were clear to me because I could see a wider context, I find it difficult to introduce them in an interesting way. While the interface is without any doubt great and easy to navigate for someone who gets the bigger picture, I think it is still overwhelming for a newcomer. When trying to learn Scratch programming using this book, my son was focusing on the final product, a computer game he could play with (and imagining one as sophisticated as the ones plays with on the DS or tablet), rather than the process of creating it. In other words, the computer was more of a distraction rather than a tool to create, or think about how to create something.
Pen and paper
This reminded me of the opening quote, and my own experience, where algorithms or programmes I develop tend to be better when I first think about them using pen and paper rather than frantically assaulting the keyboard right away.
Using the great Scratch platform as a source of inspiration, I printed
and cut a set of simple instructions on little paper tags:
Turn _ degrees, … where the young programmers had to fill
Before using the tags, we had a short discussion on what a programme (or algorithm) was, i.e. a set of steps or instructions that they would create, and that they (or somebody else, or a computer) would then execute. Each young programmer then got a sheet with a simple labyrinth on squared paper, a little character, and was asked to lay out the instructions needed to lead their character through the maze.
The exercise went quite well. Our young programmers (aged 6 to 9) all wrote their own algorithms (the most difficult part was actually getting the angles and turning directions right - the programming course was a good revision for angles and degrees) and executed each others. We even discussed what kind of metrics we could infer from these programmes; for example, would we calculate the length of the programme in number of operations or in the total number of steps?
I also prepared other instructions, such as
Repeat _ times,
Pen down. For the latter, the other adult in the team created an
algorithm that wrote her name. We saw that, despite a relatively short
name, we ended up with a long set of instructions. This led then to a
short discussion on using mini programmes that could write single
letters inside other programmes, that would write names. I had never
planned to mention such elaborated, abstract concepts, but they came
up naturally when experimenting with programming without the technical
barrier of using, or learning to use, a tool.
I think the experiment went well. For the next session, I might give them all the same slightly more challenging maze, and they would need to design the shortest path to exit, or ask them to execute some algorithms to uncover a secret word.