Why I Failed Teaching Programming to Kids
How do you teach chat bot development to teenagers in two hours? This was the challenge for me and my colleague when we set out to plan a two-hour session on mobile chat bot development for kids and teenagers.
First things first: This is a blog post about teaching, not programming. More specifically it is a blog post about teaching written by someone who is not a teacher. I am only a programmer, but hopefully my experiences could be useful to other geeky tech people who find themselves wanting to spread the word of our wonderful profession :-)
This is what this post is about:
- some background (the section Let’s Get Started),
- some planning (the section How To Make It Engaging?)
- some risk management (the section What Could Possibly Go Wrong?),
- some revelations (the section What Did Go Wrong?)
- some conclusions (the section Will I Do Things Differently Next Time?).
- You can’t prepare for everything.
- Keep your calm and adapt when things go wrong.
Let’s Get Started
Why am I writing this?
Klarna hosted a Hello World meet-up earlier this year. Hello World is a Swedish non-profit organisation aiming to get kids and teens interested in software development. Kids and teenagers can sign up for various sessions during these meet-ups. Some sessions, like introductions to Scratch and Python, are recurring and some are one-off things. Me and my colleague set out to prepare a one-off session.
I have some experience working with kids and some experience doing technical presentations for people without much computer experience but would that be enough?
Let me put it this way; I write this for other engineers who want to teach tech stuff to kids but don’t want to make the same silly mistakes that we did.
What Could I Teach?
I would imagine that mobile games would attract a lot of participants but there was just one problem: I know nothing about it.
I know about web services and other back-end technology; none of which are particularly interesting for people just starting out with programming. Could the session be about something for mobile devices without needing to deal with gaming platforms?
Interestingly enough, some messaging apps, like Kik and Telegram, have very simple APIs for developing chat bots.
This is how these APIs often work:
- Deploy a simple web service to some cloud service.
- Acquire a (free) API key.
- Implement the messaging platform’s callback interface.
- All messages sent to your bot will be delivered to your web service.
That is very straight-forward, and so it was decided that the topic for our talk would be developing chat bots for Kik and Telegram.
But Why Chat Bots?
It’s pretty simple actually: A bot can help and entertain people without them having to leave their favourite app. Sure, games are perhaps more engaging but games are also more difficult to develop. A chat bot doesn’t have to be more complicated than some simple if-this-message-then-respond-with-this-message logic. It all depends on the kind of problem the bot should solve.
Now that we knew what to talk about we only needed to plan an interesting, educational, engaging and fun learning experience. I mean, how hard can it be!?
How To Make It Engaging?
We gave this quite a lot of thought. How could we make our session engaging, exciting and fun? Gamification seems to be hot these days. The idea here is that you want to add “game elements” into your lesson to trigger some competitive nerve among students.
“Gamification is the application of game-design elements and game principles in non-game contexts.”
Gamification on Wikipedia
We decided to try these aspects of gamification:
- Use the word “challenge” instead of “assignment” or “task”. A challenge is something that you need to overcome and want to solve. A task or an assignment is just something you do because someone told you to.
- Give out stickers or other types of “achievement awards” when participants complete tasks. Sorry, I meant complete challenges.
- Each challenge would, roughly, represent half an hour of the session and completing a challenge could be compared to “levelling up” in a game.
- Have bonus assignments for participants who finish early.
We defined, and wrote instructions for, four challenges:
- Getting something very simple running on localhost. No cloud server. No API keys. Just Python. This ensures that we all have a functioning development environment and shows how little coding is actually necessary to get something simple running.
- Creating a Heroku account and deploying the code from the previous challenge to the cloud. This ensures that we all have the necessary tools installed.
- Create a chat bot account for Kik or Telegram.
- Deploy a chat bot to the cloud.
Start with simple stuff and then dig deeper, basically.
What Could Possibly Go Wrong?
Now that we had a topic and a plan we thought it might be a good idea to account for the unexpected. We discussed what problems we might encounter during the session.
“I am prepared for the worst, but hope for the best.”
Benjamin Disraeli (1804–1881)
How Much Do They Know?
It’s hard to gauge and predict expectations and skills of participants in these kinds of lessons. Do they expect to just try things out or to be given a lecture? Do they have the prerequisite knowledge and interest or did they just chose to attend because other sessions were already full?
We chose to assume that the participants would have developed some basic Python applications but nothing else. It would have been preferable to require, or assume, some knowledge of how the web works (web servers, cloud computer and so on) but we did not expect any such knowledge.
I personally assumed that our session would attract mostly teenagers because I assume that instant messaging is used by more teenagers rather than younger kids.
How Much Do They Want To Know?
Should you explain every step or just tell them “do this and then do that”? Just following instructions without understanding them doesn’t do much good, in my opinion. Then it’s just mechanically performing tasks without any reflection. I guess it would be okay to just follow instructions if one later revisits the code and reflects on what it does but there is a big risk one does not take the time to do that.
In the end we chose to write our instructions with short descriptions sprinkled in here and there.
The Show Must Go On. Let’s Scrap This Step.
We knew that we might have to throw a lot of the planned stuff out the window because we did not know anything about the participants.
It is obviously hard and time consuming to prepare for the unexpected so we settled on acknowledging that things might have to be changed on the fly during the session.
Dö Yöu Underständ My English?
I am fluent in Swedish but my colleague is not. Would this be a problem?
I did not think much of this given my assumption that most participants would be teenagers. Teenagers in Sweden have been taught English in school since early years and they consume a lot of music, TV and text in English. We settled for writing the instructions in Swedish and then, if necessary, switch between English and Swedish when talking during the actual session.
Ok, So What Went Wrong?
The day of the Hello World meet-up came. It was a very intense day. In the words of my teaching partner:
[The day was about] the humbling experience of teaching kids how to code.
Before I continue, I would like to point out that a lot of things did go according to plan during the day. However, being an engineer I tend to focus on the bad stuff. The things that annoy me. Things I know could be improved.
That being said; let me now briefly mention some things that didn’t go according to plan…
The day of the lecture (or should I call it the lesson?) came and the kids arrived. I say “kids” because they were not as old as I had expected.
As previously mentioned, I expected chat bots to interest teenagers but instead our participants where more like 9–13 years old. This obviously affected how acquainted they were with “common development tasks” like using a terminal, installing applications and creating files with weird names like
Pre-teens also require more attention and more explicit instructions, which forced us to be more hands-on instructors, which introduced delays.
The fact that the participants were younger than expected also affected how well we could communicate with them. The kids were surprisingly good at English and most of them could talk effortlessly with both of us. Having said that, I still spoke Swedish most of the time since it was in fact the mother tongue of the kids.
Try to get an idea of the participants ages before the session.
Either only talk Swedish or make it clear during sign-up that not all instructors are fluent in Swedish.
Unusual Format For Instructions
We had found this really cool library for creating web-based slide shows and we used it for the slides we showed on the big screen in the room the session was held in. This worked well.
We used the same slide show tool to write the step-by-step instructions for each of our four challenges. This did not work well. The instructions had to be split into multiple slides and some participants did not immediately understand how to get to the next set of instructions.
Links to the instructions were shown on the big screen in our room. The kids could then read the instructions on their own computers by simply typing a bit.ly link. At least that was the idea.
Unfortunately it was easy to misspell the addresses and this added unnecessary confusion and frustration for something as simple as getting some instructions.
Do not try to be clever with instructions. Step-by-step instructions should be given in plain documents, either electronically or on paper.
In an effort to produce fancy slide-based instructions we didn’t have time to ensure consistent styling across all slides. This resulted in some console command being printed in a body text font whereas some were shown in a mono-spaced font. This made it hard to know what was instructions and what was source code.
Make sure everything follows the same style guide.
Confusion Ensues When Running Out Of Time
We noticed quite early that we would have trouble finishing on time, or at the very least that many of the participants needed more time than expected to get started.
When more than two thirds of the session had passed we still hadn’t gotten past the halfway point. Not good. We tried to jump ahead in the plan by skipping the third task and moving on from the second to the fourth, and final, task.
This wasn’t a big problem since we had prepared one source code package for each task and each such package was self-contained in the sense that you can download any one of them and get something fully functional. However, skipping one step also meant that we had to change our instructions in the middle of the session. Not ideal.
It was a good idea to have pre-packaged the necessary source code for each task but in the end it didn’t matter that much since we were short on time anyway. The lesson learned is perhaps then that things always take more time than expected. We should have known this but we humans are really good at deceiving ourselves when it comes to time management.
When it started to dawn on us that we wouldn’t have time to finish all the steps we became noticeably distracted for a while and the kids obviously noticed this. This lessened their interest. The thing I take away from this is to always keep the spirit up. In our defence we did try to do that but it wasn’t enough.
Say What? This Is Not Your Computer?
Two of the kids had trouble using their computers for one very simple reason: They have never used them before.
One participant usually used a computer with Windows but this particular day he had borrowed his father’s Mac, meaning that everything from file management to console windows was unfamiliar to him.
Another participant had borrowed a vanilla Windows tablet from Hello World which, obviously, didn’t have the required tools pre-installed.
A third participant could not connect to our office wifi. In the end we solved the problem by enabling the wifi hot-spot on my mobile phone and letting him connect to that one instead.
Additionally, some of the computers had Python but not Pip (the Python library manager). We had identified this as a potential risk but considered it to be minimal since we had tried installing Python on both Windows and Mac without running into this problem.
Not all participants will have read, understood or completed the prerequisites. Deal with it. Plan for it.
Wait… What Was My Username Again?
Developing a chat bot like ours requires you to keep track of a some things:
- cloud platform account credentials,
- your Kik or Telegram account credentials,
- the bot’s own credentials.
It is easy to get these confused when you are a beginner.
Make sure participants choose names which are guaranteed to be unique, like “helloworldklarna_alice” or “helloworld-banana”, if the task at hand requires them to create accounts with major service providers.
Will I Do Things Differently Next Time?
I learned a lot during this experience, both during the planning stage the execution stage. Let me quickly summarise it for you.
The main problem turned out to be our four-challenge plan, which started from scratch and then added complexity.
This turned out to be a less than perfect idea because the initial tasks had very little to do with chat bots, just programming and web services in general, and those tasks consumed so much time that we never had time to do the last and most interesting task. The final task was the crowning jewel, the task that was absolutely necessary in order to get the chat bot running, and we ran out of time before we got there.
If I get the chance to do this session again I would structure it completely different. I would start with a complete and fully functional example. Make sure everyone first have something fully functional up-and-running and then move on to describing how it all ties together.
Adapting To Change
How do you quickly adapt when you notice that things are taking way longer than planned? Do you accept it? Do you jump ahead?
The next time I am faced with planning a similar session I will make it easy to adapt to change during the actual session by planning it in terms of separate half-hour assignments (the “challenges”). It should be possible to get started with a challenge without having completed any other.
Everything needed to complete a specific task, including instructions and source code, should be readily available and downloadable without having to look at other assignments. This means that we can still plan to do tasks in a specific order but we can skip or reorder if necessary.
Good Instructions Are Hard To Come By
Handing out instructions as slides instead of documents was a bad idea: People are not used to it and it caused some confusion.
On the other hand; online slides, compared to static instructions on paper or e-mail, gave us the ability to change them on the fly when we realised that we needed to change the session.
The lesson learned is that slides are good for what you want to show to the whole class. Step-by-step instructions should be handed out as regular documents, either online or on paper. Electronic documents are probably preferable since it allows participants to copy and paste commands. Nothing of this should be news to anyone.
This is a pretty small thing overall but right at the start of our little lesson we touched upon pair programming. We mentioned to the kids that we thought it would be a good idea if they could pair up and cooperate on the assignments. They were not thrilled by the idea, and I can’t blame them.
Pairing up does not work with kids who don’t know each other. This actually has nothing to do with programming but instead relates to people in general: Being in a room full of complete strangers is never fun and being asked to collaborate with them on the spot is not something everyone is okay with. Maybe next time I’ll start by asking if anyone wants to collaborate, pair those kids up and let the other kids work on their own.
Anyway, this was no big deal and the kids did try to help each other out when they got stuck on something, which was nice.
The Future Of Our Society
My final, and maybe most important, take-away from this whole teaching experience has nothing to do with the teaching experience at all. Instead it is about the brilliant kids growing up today!
The future looks really bright. The next generation of software developers (or should I say the new generation since these kids are already putting their applications and games out there?) will be amazing developers!
They are motivated, interested and curious. They will be, if they are not already, fluent in English. They will know how to find a solution to pretty much any problem, either by searching the web or by developing software which figures it out for them.
I’ll end with what one of the kids talked about during a break:
“Could you tell me more about Klarna? Me and my friend are developing a subscription based service and we have been looking into different payment solutions but are not happy with them: We don’t like Paypal’s 30-day charge-back policies and we don’t like that Swipe cannot do recurring payments.”
/Hello World meet-up participant
The future looks bright.