I write a lot of educational resources, so I thought it might be useful to share some tips for things I’ve learnt over the years. I’m hoping that these tips will be particularly helpful for those people in the wider community who volunteer to give up a lot of their time to run workshops for kids but who don’t necessarily have formal training in education.
Avoid a wall of text – Before you start writing anything at all, think about how old the learners are. If you’re working with very young children (5 – 7 years old) you will need to keep the written instructions to a minimum and use lots of pictures and screenshots. As the children get older they can cope with more verbose instructions…up to a point. Children don’t read instructions, and it’s not because they are naughty, easily distracted or can’t cope with the task. (Most adults don’t read instructions properly either!) Use pictures and diagrams as much as you can in place of lengthy explanations.
Check the level – The most common mistake I see in resources not written by teachers is vastly overestimating the level a child will be able to cope with. I’ve seen people assume that 8 year olds can cope with things that are introduced at A-Level. I’ve also seen people saying the equivalent of “the 7 year olds in my programming club wrote a recursive fibonacci sequence function last week”. No they didn’t. *You* wrote a recursive fibonacci sequence function last week and they copied out your code. If you’re not sure what level is appropriate, ask someone! There are plenty of experienced educators on twitter who could field your question. (Of course there will always be individual children whose capabilities far exceed their peers, but suitable tasks for a workshop should be designed with the average attendee in mind.)
Don’t make them type the hard stuff – If the thing you want to create requires a little bit of difficult code that is beyond your learner, that’s fine. Don’t make them copy out unintelligible (to them) code and say “don’t worry about what this does” though, give them a starter file with your code inside it. You could also consider using a site like trinket.io where you can add your code in a separate tab and let them get on with their bit.
Give clear instructions – When you ask the learner to perform a task, make the instruction for what they have to do explicit and clear. “You’ll need a forever block”/“You can use a forever block” is not as clear to a child as the direct instruction “Add a forever block”.
Explain where to add code – One of the most common sources of confusion for learners is being asked to add some code to their program but not knowing where to add it. Be very clear about where new code should go (“add this code as the first line of the blah() function”), or use a screenshot with line numbers or an arrow, for example:
Add the code to import the random library here:
Allow play and experimentation – The end goal of a tutorial or workshop is not to recreate the exact program you envisaged when coming up with the workshop. The end goal is that the learner learns something and has fun doing it! Try to plan for this in your task by allowing them to personalise the task (“Add your own page title between the <title> and </title> tags”/ “Choose a sprite to represent your player”). Does it really matter if their maze game character is a floating piece of cheese rather than Pacman?
Explain why – If you’re asking the learner to copy out some code, explain why. Compare the following approaches:
Add this code:
This line of code will open the file a_file.txt in read mode (r) so that you can see what’s inside it. Add the code at the end of your program.
Not too much too fast – I’ve seen resources for kids that start off by explaining variables, selection, two kinds of loops and functions within the first two paragraphs, and then expect them to be used fluently throughout the rest of the tutorial. It’s not going to happen. Don’t assume that because you explained something once it was understood.
One does not simply – Avoid using phrases which trivialise the instruction (“Simply add a function to invert the wobblybobble”/“It’s easy to add some code to jiggle the flimflam”). It might be easy or simple for you, but for the learner it might seem extremely tough, and there’s no reason to make them feel bad unnecessarily.
Choose your words wisely – The Wikipedia definition of a variable is “A storage location paired with an associated symbolic name (an identifier), which contains some known or unknown quantity of information referred to as a value.” I’ve seen definitions along those lines in resources intended for kids. You need to simplify a concept as appropriate for the age group, for example you might say “You can store data inside a variable, and each variable has a name”. Also think carefully about throwaway words you use – it’s unlikely that most kids will understand words like API, native, REPL, mutable etc. or be able to infer their meaning from context.
Think about their background – Younger kids type reeeeeally slooowly. Think about how much typing there is for them to do, and how frustrating it might be. Can you reduce unnecessary typing by providing some starter code? If you’re using concepts from maths or other areas, think about when these are introduced in school. For example, kids start learning about coordinates in Year 5 (age 9-ish) so younger children might not cope if your workshop assumes they know what a coordinate is.
Remove the stabilisers – Once your learner reaches the end of your tutorial, is there an open ended task for them to do to build on what they’ve done so far? If there is, it will reap dividends for you as it keeps the learner gainfully occupied whilst you help slower workers, lets them have fun experimenting and will be the acid test of whether they understood what they just did or just copied out your code!
Leave a comment with your own top tips! 🙂
Code? Boom. 
When writing instructions for children (or anyone!) use an easy to read, sans serif font.
These are great. One other difficulty that comes up is the use of placeholder text in example code. Like YOURUSERNAME. Students of all ages often interpret such text literally. The best strategy I’ve found is to describe a protocol generically, and then provide a real example.
Remember what a range there is in student ability/motivation. Standing up at the front and defining a variable as such and such in front of 30 kids is going to be gobbledygook for 33%. Use peers/extra adults to help re-explain; teaching is about never saying something only once.
You have neatly described everything I have done wrong with my attempts to write worksheets for my code club! Thank you, this is so useful. My second year of code club is going to be so much better from what I have learned during the first year, and from reading this blog entry!