Following on from the post I made a while back about writing resources, I thought a post about things to consider when running a workshop for beginner coders might be handy too. This post is primarily aimed at those lovely people who have no training in education but who give up their time to teach other people how to code.
It might seem obvious, but you need to prepare some things in advance to make sure your workshop runs smoothly.
Before you even start writing your workshop, think about the name of the workshop. I often see workshops for kids with titles like “Control a HC-SRO4 in Python”. You might know why this is cool, but why would a 7 year old want to do this? Do the same workshop but call it “See like a bat”, add a bit of fluffy story about bats and you’re on to a winner. Never underestimate the power of the fluffy bits. (This also works with adults!)
When you plan a workshop for beginner coders, I would always recommend that you do the task in advance using your own instructions – and even better, get someone else to do it too. No shortcuts – follow your instructions to the letter. It is amazing how many mistakes you can filter out this way. As a teacher, on a couple of occasions I set programming tasks to students which turned out to be INCREDIBLY hard, but I hadn’t done the full task myself so I had failed to spot the problem.
When you test your workshop, make a note of how long it takes you to do the task. I once ran a workshop for Year 4 girls which involved making a badge by sewing an Arduino GEMMA and two LEDs onto some felt, then programming the lights to flash. I practiced the workshop myself, noted down how long it took and decided that 3x the time it took me was fine for the age group. It wasn’t fine – in fact it was probably the worst workshop I’ve ever run, because I failed to take something crucial into account. Almost all of the girls that young had no experience of sewing a basic running stitch. I wasn’t teaching a sewing workshop, but I did assume they could sew. The moral of the story is that you should mentally scan your workshop plan for assumptions that may be completely unrelated to what you are trying to teach, and then check your assumptions are in fact correct.
This might sound like an odd thing to think about, but plan the questions you will ask, and also think about what participants will ask and when. Having an answer for a logical question ready at the right time is much nicer than shutting down inquisitive participants with “we’ll get to that later”.
On the day
If your workshop involves copying code, think about how the participants will do this. If you want them all to copy from a projected slide, is the font big enough to see? Are there any seating positions with a poor view? Have you considered colour blind participants? This strategy also forces everyone to move at the pace of the slowest person which might cause frustration, and makes it harder to fix typing errors once the slide has moved on. In general, I much prefer a handout or an online document participants can access at their own pace. (See also “Don’t make them type the hard stuff” in my resources post.)
Open the necessary files you need on your laptop before the workshop starts. Watching the presenter navigate their desktop (whilst craning their neck awkwardly because of the angle the laptop is attached to the projector) is not a fun workshop experience.
When you begin the workshop, take a few minutes to define some rules with the group. Usually you will be running the workshop in a fun setting so it’s not supposed to be like school, BUT as a participant there is nothing worse than people talking over or interrupting a workshop when you’re trying to listen. With adults you can usually skip this step, but on occasion it might become necessary to raise the subject. It’s a bit cringe having to do it but people will thank you – I remember one stressful Picademy where we were in a particularly small and hot room and I had to remind some participants not to talk over the session 😦
Within this, decide on a way of getting people’s attention so that you can transition smoothly from bits where you talk to bits where they code. Most kids will be familiar with a raised hand – this means everyone in the room raises a hand and waits, and eventually your signal for attention filters around the room without you even having to say a word. Nothing more stressful than trying shout over a noisy and enthusiastic room “um…uh…could you just listen a second please?”.
Think about the language you use and the way you present tasks. My workshop motto is “One does not simply” – don’t proclaim anything to be simple, and don’t skip over things you think are too basic to cover. There are also small nuances in the way you check understanding – it is much better to ask “Is anyone confused?” after your explanation than “Does everyone understand?” or you’ll end up with a response like this joke:
Three Computer Scientists walk into a bar. The barman asks “Do you all want a drink?”. The first Computer Scientist says “I don’t know”. The second Computer Scientist says “I don’t know”. The third Computer Scientist says “Yes”.
My last and final tip is probably the most important. Have a backup plan. This is a backup plan for better or for worse – the workshop might go stunningly well and you get through the content in half the time and need some more, or you might need to deal with an unexpected problem. You don’t need to have a fully inflated life raft waiting in the back, but you do need to have a rough idea of what a life raft looks like and know how you might Macgyver one up if the situation requires.
Good luck, you’ll be awesome!