Lessons Learned From Running A Code Club

Here in the UK we have an organisation called Code Club which aims to help all children learn to code. It's a network of volunteers and educators who run free coding clubs for 9 to 11 year olds. I have two children, aged 7 and 9, and I want to encourage them to learn more about computing and technology and not just watch gaming videos on YouTube. When my eldest son moved from his infant school to his junior school a couple of years ago, the teachers told me how ill prepared they were for the move from Information Communication Technology (ICT) to computing. This was due to ICT being more about how to use a computer rather than how to write computer code. Having over 20 years of professional programming experience, I thought that this would be a good time to get involved to help my son's school. Unfortunately, due to almost dying, it took a bit longer to help out thank expected but I finally started running a Code Club this year. It's harder work than I imagined but it's a fantastically rewarding experience. Here are a some lessons I have learned along the way which could help others.

My original plan for my Code Club was to teach one group of children for around 10 weeks. I decided to only run the club for the Y5 and Y6 pupils, ages 9 to 11, and my plan was to start with the basics and continue to build on the projects each week. When the school announced the Code Club it was over-subscribed with around 30 children enrollong. Instead, I ran the club for two 5 week periods with 15 students in each class.

My wife is an English teacher of over 17 years. She laughed at me when I returned home after the first lesson and exclaimed "that was hard work". Any teachers reading this will also be laughing at my naïvety. I blindly assumed that all children would listen and implement the coding lessons I'd prepared. They did. Sometimes.

Some children will listen. Others, not so much. There's noise, there are questions, somebody needs to go to the toilet, everyone needs to go to the toilet, somebody is showing the whole class their project and so on. It's great fun but it can get chaotic. There's a great article about embracing the chaos on the Code Club website that everyone should read. I quickly realised that allowing them to do their own thing was part of them building their confidence in computer programming.

I had a class size of 15 children in each group. As a non-teacher, this felt like a good class size to be able to control. For the first two weeks of Code Club I was alone in teaching until another parent helper had received his DBS check. It is harder than I imagined to be able to teach a class and answer all of their questions with one teacher and 15 children. Once an additional pair of hands was on-board, it made teaching much easier and big thanks to Dan for helping every week.

I chose to use Scratch for all of my projects. It's a good choice for drag-and-drop programming and introduces the children to the basics of computing in a simple environment. It avoids complicated syntax errors when using a language such as Python or JavaScript. Most of the children had used Scratch at school but there was a range of abilities. Some questioned the basics while others raced ahead adding new features to their projects. My Code Club is in the school library so I always introduce the lessons with a set of slides on the TV. I introduce the lesson and talk through the basics but then have a set of enhancements that the children could work towards if they have the time. This helped to set the goal for the slower students while challenging the quicker ones. I also shared my version of the game as a challenge to make their's better than mine.

It's perhaps an obvious point to make, especially if you're a teacher, but you should always run through the Code Club resources a couple of nights before. This helped me to understand the Code Club approach to the problem which often differed to my own. As I mentioned above, I always create a "stretch goal" for the children to try and achieve. This could involve improving the graphics, adding start and end game screens, adding sound and any other fun ideas I could think of. This ended up as a great challenge for me too. Scratch is restrictive when you're used to writing complex applications or games but working out a Scratch-based way of thinking was great fun.

I ran the "Rock Band" project on my first club. The sound of 15 computers blaring out sound effects can be tricky to manage, especially when the children find the music! Ask them to keep the noise down. If you're lucky they will. You may allow the use of headphones too.

Scratch provide the children with great graphics and sound effects but they want to make each project their own. For my initial Rock Band lesson, I also showed them a Pikachu version as I knew seeing a Pokemon would get them engaged. I'd put the graphics on a USB stick but formatted it on my Mac. My fatal mistake was not formatting it for a FAT32 file system so it didn't work and there was some disappointment. The other issue to consider is whether the computers have internet access and whether the school allow access. You'll find that they want to download graphics to personalise their projects so you'll need to decide if this is possible. Thankfully, most schools have good safety policies and internet filtering. If the children can use their own graphics, their projects become their own.

Show the children the costume editor in Scratch and they can start creating their own sprites or variations of the existing ones. They love doing this but be aware that they will spend the whole lesson drawing sprites if they can.

In software engineering we have a method of finding problems in our code known as rubber duck debugging. The idea is that in telling the problem to someone else, such as a rubber duck, you'll actually understand the problem and will explain the solution yourself. If you've never tried it before, please do. It works! The children sometimes couldn't work out why their code didn't work as expected. Instead of pointing out what was wrong, I'd ask them to explain what they've done. I'd ask questions about each line of Scratch code. Most of the children would instantly see the problem and could fix it themselves. Computer programming is all about failure. You have to get it wrong to fully understand how to correct it.

I use a MacBook Pro for work. I am a developer who needs high end technology to do my job. Schools are not the same. They have constant budgetary constraints. They need to decide where to spend their hard fought for money. It won't be on the best computers. My son's school had reasonably usable Windows laptops with the latest version of Scratch on them. We generally had no issue with them. However, I helped out with teaching some programming at my daughter's infant school and it is a different story. They had half a room of desktop PCs and around 10 or 12 notebook-style laptops. The desktop PCs were fine but the notebooks had tiny screens and missing keys. The Scratch interface didn't fit on the full screen meaning that children had to scroll up and down to add new script blocks. It was much harder for the children couldn't to do this.

One of the best ideas I used was to have a "show and tell" at the end of the lesson. I didn't start this until the second week but it finishes off the lesson extremely well. The children like to show their own unique take on the projects. I was often amazed at the direction the children took and it made for interesting learning for me too. Show off their projects on the big screen or projector if you have one. Make sure all of the children watch as it encourages their creativity for next time. Remember though, if you have 15 in the class, it can take quite a while to share each project. I initially gave 10 minutes to do this but ended up needing 15 to 20 minutes in the future weeks.

Ultimately, you and the children both need to have fun. Some of the children told me "it was awesome - I can't wait for next week". It's been a pleasure to teach them all and I hope tht I've influenced some of them to eventually follow a path into software development. If you don't run a Code Club then why don't you try? The Code Club website allows you to search for clubs in the local area where you could help out. Or you could start one yourself. You don't have to be a computer expert to start one. The children will help you if you get stuck!

If you're interested in following a similar structure to my club, here are the projects that we did. I've also listed some of the enhancements that I added and have given links to my versions so you can use and alter them.

Week 1 - Rockband

This project gives a great basic introduction to Scratch. It shows how to play sounds, change costumes based upon state and about user input. I expanded upon it with my Beatbox Pikachu version.

Week 2 - Ghost Catcher

This is a "whack-a-mole" style gme where you click on ghosts as they appear and disappear to score points. A great introduction to variables which record the score and display a timer. Enhancements could include varying the frequency, size and speed of ghosts and adding a high score. My version shows a complete game with a game over screen. You'll find my Ghostbusters game here.

Week 3 - Chatbot

Ths is probably my favourite project. You add code so that Scratch asks a question and the children use the response within their code. It gives a great introduction to computer logic, for example "if...then". I started simple but then asked them to create their own "artificial intelligence". My enhanced version is an AI which responds to simple commands such as "hide", "moonwalk", "basketball", "dab", "bottle flip" and my character responds accordingly. Bottle flipping was one of their favourites and everyone tried to recreate it! 😄 Here's my version on the Scratch website.

Week 4 - Clone Wars

This project was particularly enjoyed by the Y5 children in my second group. It's a space shoot-em-up with a Galaxians feel to it. In this you learn about cloning sprites for spawning bullets and enemy AI. This is an interesting project for explaining how I would experiment with variables to create a fun game. Show them how to change the speed of enemies, the time between bullets and what difference it makes to the game. My version adds a shield, lives and a game over screen so it's almost a real game. My version is on the Scratch website here.

Week 5 - Flappy Parrot

This final project was the one that the Y6 children were most excited about. Flappy Bird is an iconic mobile game for most of them and it was great to see their ideas - Flappy Taco anyone? It introduces more complex movement to the children in the form of gravity. It also shows the game developer trick of pretenting the bird moves forward by actually moving the pipes backwards. This was quite a mind-blowing trick for some of the children but great to see them understanding it. This is also a good project to show a full set of game states with. Try adding a start and end screen. Mine used the original Flappy Bird graphics and awarded a medal if you beat the high score. You can find my version of Flappy Bird here.