Every Tuesday night, a few of my friends at work and I head to a nearby youth centre to teach a class about programming to junior high school students. Our initial goal was to teach them javascript using codecademy‘s tutorials and our own guidance. We have failed to meet that goal.
On the plus side, we (and the kids) have learned things, and we’re sure it’s been a net positive experience so far, but we’ve got some changes in mind to make it even better. I’d like to share our situation, how our lessons have gone, what we’ve learned, and our plans for the remaining weeks of the program. Hopefully this can be of use to someone in the future, even if it’s just us when we try again.
Our Background
Our team is about half programmers and half people who work in other roles at the company. One fella in particular in our group has headed up the majority of the curriculum choices and plans for this program, and I’ve done my best to assist him along with a group of seven other volunteers. None of us have significant teaching experience – I think I might top the list with four or five courses as a teaching assistant. The class has about 15 kids at a maximum, and we tend to have 5 grownups in the room, teaching from 5:30 to 7:00 PM. We hoped that we would be a good natural fit for teaching programming as people who either know how to program or are learning it at present.
Our Plan
Initially, we believed that we’d be working with high school kids. Our plan was to use codecademy’s codeyear tutorial series to try to build a game of blackjack all the way from fundamental syntax. We worked through the first block of lessons in 20 minutes or so to review it, and felt like it would be reasonable to expect high schoolers to get through it in around 90 minutes. Then we found out it would be junior high students, and because we didn’t have anything else, we decided to give it a try as planned.
How the lessons went
(this is a lengthy narrative format; there’s a summary at the end)
Our first lesson plan was to introduce ourselves, get the kids to introduce themselves, show them how to get to the website, briefly walk through using it (type into the window, hit enter, follow the instructions, etc), and then loosely supervise the group, helping when necessary. The general plan worked well. The kids followed the instructions and typed things in, but only got through the first 3-4 lessons of the first block in an hour and a half. What was worse was that afterward we felt like we hadn’t taught much, and that the kids had gone through the motions, but hadn’t learned much either.
The next week we decided to keep the same approach because we had only a hunch that our lessons weren’t hitting their target. We knew that the kids would start to run into walls during the lesson if they weren’t getting it, so we did more codecademy with a bit of review of the concept of variables at the beginning of class. The kids did not seem enthused by the material, but they worked at it. One or two kids got to the end of the lesson block, and most of them got to lesson 6 or 7, about conditionals or loops. We took note of the failings of the codecademy tutorial and the sort of questions that we were being asked. Some of the kids clearly did get it, while most did not.
We discussed the situation before the third week. We felt like leaving codecademy would be abandoning our goal, leave the kids wondering what was up, and could leave our course without its core value. We wanted to try something else though, so we introduced the class to LightBot, a flash game where the object is to move a robot around an environment by giving it simple commands with a drag and drop interface.
This seemed to interest some of the kids more than the javascript, though it seemed to be a bit more confusing too (it required some understanding of functions to get through later levels, and our attempts to explain the concept in an odd context like the video game didn’t always get through. We noted that the kids were definitely doing more problem solving and were clearly more engaged on the whole.
Before week 4, the team researched MIT’s Scratch, CMU’s Alice, the Logo language, and simple Javascript canvas playgrounds, but nothing felt cool or easy enough to be a great choice. Then a member of our team found a program called Kodu, which blew us away, but the computing resources at the youth centre couldn’t handle it. We went back to the drawing board, and ended up using the second LightBot game in week 4’s class. The kids were much more savvy this time around, and several came to grasp the concept of simple loops and functions in the game’s context.
The following day, we had a phone call with an instructor who has run a number of short programs intended to teach kids about programming, and we barraged her with questions about her experiences and about what our goals should be. We found out that she had made use of Scratch, and that the kids in her program (who were a little younger than ours) loved it. She also had a fantastic takeaway for us — don’t worry about teaching concepts. It’s not important that kids leave our class with strong computer science fundamentals. They’ll do that naturally if they are excited about code when it comes up later in their lives. It’s our job first and foremost to bring a sense of joy to messing around with computers, and they’ll figure the rest out on their own.
To summarize, we began trying to teach javascript with a self-driven tutorial and hoped to convey concepts. We found that this approach was not working well, and that engagement rose when we played a game based around the concepts instead of working through examples. From there, we’ve been advised to aim for excitement and to worry even less about concepts. Motivation will make concepts take care of themselves down the road, so it should be our focus.
Next steps
Our current plan is to introduce Scratch using some teaching materials we’ve found*, along with our aim to excite and advice from a coworker who taught high school students in the past. After a week or two of introduction, we hope the kids can spend the last few weeks building their own scratch games/videos while we help them to get past any roadblocks they encounter.
We’ll be taking a more hands-on approach to teaching the Scratch program, having the kids see small sections of the steps played out and repeating them. We hope that we can bring more excitement to the class, give the kids an opportunity to create something, and let them take home a more positive view of making things with computers.
Conclusion
I don’t want to paint the image that the kids have been unhappy; the man who supervises the outreach program put our minds at ease by reminding us that if the class were totally awful, far fewer of the kids would keep coming back. We have just felt a consistent belief that we could do more for them, and we think that we’ve arrived on a better path now than when we started.
Also, as a final (nitpicky) note: codecademy is not a very good platform for teaching kids. The biggest nits for me to pick in the initial block of lessons is a lack of consistency and very difficult language / abstract examples. The first few variables you declare are myName, fullName, and myLastName — the kids got confused about why and whether the ‘my’ needed to be at the front of what they were writing.
Beyond that, names are often things like “array” for an array, or examples occur like a variable “word” which holds the word “this” or the word “that”. It’s entirely too complex and abstract. Attempting to explain an if statement evaluating the variable “word” which may have “this” or “that” inside it quickly turns into a “Who is on first” situation. These could be rewritten to use more concrete language. For example, a variable can be descirbed as being like a jar with a label on it that you put pickles or berries into. That level of concreteness would have made our task worlds easier.
We considered writing our own codecademy lessons to continue down the javascript path, but in light of the extra research we did, Scratch is by far the best route for kids in the age group we’re teaching. Codecademy has its place and is a great resource, but those initial lessons could be vastly improved.
Unrelated Addendum
As a final and very marginally related note, I tried writing this out on piratepad so that I could replay my writing process in an attempt to improve it. I ran into two major problems.
The horizontal resize bar decided to operate on hover or somehow to interpret hovers as mousedowns. Every time I moved the mouse, the text writing field started resizing itself. I resorted to being extremely conscious about keeping my mouse to the left of the margin bar, and using the keyboard for any window/tab switches or text selection I might make; it was a big darn pain.
Next, the pirate pad server apparently went down while I wrote. A “re-establishing connection” notice came up, and presented an option to “Reconnect” as the big clear nice-looking button. Doing so refreshed the page, which would have been great if the piratepad server had not just gone down. I checked its status using downforeveryoneorjust.me, and waited 5 minutes. It fortunately came back up! And to the service’s credit, my writing was preserved across the gap. The experience was very scary, and comes down to the simple UI issue of not suggesting a user reconnect without warning them to copy their text away first.
* If I find the URL to these lesson plans, I’ll insert it. If you’re looking for them after reading this and I haven’t done that yet, please email me.