Ask HN: How to best teach a group of children how to code?
Hi HN!
I run an education focussed r&d shop (www.jibly.com) and regularly work on mobile app projects for large firms.
This year, I wanted to start teaching a group of underprivileged children (orphans, refugees, etc) anywhere in the world, how to code for every commercial app project I do for companies.
So for every app project I get, a group of kids gets the tools and resources to learn how to code.
I'm thinking of donating laptops with pre-installed child friendly coding environments. Including books, manuals., etc..
What are some great ways to teach groups of children how to code, without being present every day?
115 comments
[ 1.9 ms ] story [ 282 ms ] threadOne kid wrote a basic brick breaker and another pong. They all seemed to enjoy the process since it's pretty straight forward drag/drop logic.
https://scratch.mit.edu/
Doing it on paper by hand first is more important then it sounds, so they can really understand a)what they are coding, b)how fricking awesome computers really are.
https://www.ted.com/talks/sugata_mitra_shows_how_kids_teach_...
I've been planning on using Mozilla's Learning program (https://learning.mozilla.org/en-US/) a shot.
It's 2 separate sessions (1 for each age group) and 2 weeks in total. I have already outlined my plan based on it that I'm happy to share.
Does anyone have experience using their platform - share some thoughts?
TLDR: Focus on getting them to have fun & enjoy learning about 'code'. Don't care so much on how well they learn it.
Every kid is unique & will respond to different things.
Social & mentors are awesome. It's usually more fun to build with others if possible. Also they will want to easily share & show off their creations with others.
Show them how to "hack" Google with the browser's dev inspector tools. Wins them over every time.
Give them simple partially completed programs that they can modify. I've had a lot of success with a simple trivia game that lets them start by modifying the questions/answers & the replies it gives. A great first lesson in how to use strings & gets them looking at the code. They can then share what they created with others (social aspect) & have them play their game.
Do NOT lecture to them or try to do long demos. They often listen to teachers lecture all day long. They want to have fun & explore. They also don't care about types or any other computer science terms until they've created a lot of things & are trying to figure out why they don't work.
I've had decent results with Scratch. For pure beginners though, still start them off with a semi-completed program.
Another suggestion that works for the same reason is to give kids code to play with. I've wasted 20 minutes of class time having kids write a three line "Hello World!" javascript program from scratch. All this did was irritate and bore the kids out of their minds as they struggled with syntax and hunt-and-peck typing.
Instead, when I give kids a great big block of javascript code that does something fun and animated, those kids will go wild with it. This is because changes to different variables can have big effects. They quickly learn to read the code and identify what different parts do. They break the code, and you show them how that's a good thing and how easy it is to revert it back so that it's working again. Code should be a playground. Give the kids a rich playground to run around in.
I remember being a kid and typing in Mandelbrot code from a BASIC computer magazine. Even though I didn't understand the code, I had endless amounts of fun with stuff like that for exactly this reason.
It's what sparked my imagination and interest in programming.
Got some script for modifying a game or an excel function or some code that doesn't quite do what we want it to. Bash it with random changes until you suddenly fix/change/etc. it.
Get a bit addicted, rinse, repeat, suddenly a month later you can understand most of the code.
It's too bad elementary and secondary education in general aren't more like this.
The plan was to teach kids about how websites works/HTTP basics, basic HTML/JS etc. I had all the material and code ready. When I reached the school I found out their internet had been disconnected!
Google's "browser is offline" T-Rex game popped up and I ended up spending the entire week with them teaching them how that game worked. It was a big hit! By the end of the week they were busy modifying the t-rex sprites with each others faces and stuff :)
Basically have a back up plan for no/limited internet!
We had a lesson plan booklet to work from, but I found it far more effective to completely ignore it and let the child explore, and then guide the result of that exploration into a result. Seeing the sheer delight on a kid's face when you point out that with a few minor modifications, what he or she has made is in fact a playable computer game is spectacular. (and then beatboxing with them to record "background music" and sound effects is also fun ;) )
I have learned not to bore them with business apps or too much of the logistics to start. I start by getting them to code basic HTML/CSS. They get super excited by learning how to change colors and font sizes. Then we go into programming some simple JavaScript games. Later in the course, I bring in a Raspberry Pi and introduce them to that and a little Python.
You don't want to scare them away or overwhelm them at first. Keep it exciting and fun. At this age, let them hack.
Teaching kids to code is similar to teaching just about anything else: get them to have fun and find how it applies to them, followed by how to figure out what they don't know, then how to keep going when things are frustrating and they want to give up.
More practically, the kids who are into games have probably already figured out how to write Minecraft mods or something, so introing them to something like Code Combat is a fairly natural next step. For kids into music, try http://sonic-pi.net. Sports? Maybe wade into statistics/data analysis and show em some moneyball or fantasy football. Lego Mindstorms-style stuff is awesome for just about everyone because of the tactile aspect, and moving from that to playing with simple electronics can be done with gentle happy path introductions.
Also be aware of where the falloffs will be. Lots of kids can change the color on a prebuilt object on Khan Academy, but going from changing a field to starting from scratch on a new idea is an incredible. Teaching debugging and figuring out how to solve something you haven't seen before is more important than anything else.
YES. I wish I could upvote this more. Curiosity is a powerful drive for learning, and when kids are allowed to pursue their own line of questioning and tinkering, the questions asked are more "personal" and the information learned IMO is more likely to be retained.
The "zero-entry pool" that Scratch provides is also important (how many kids want to spend a lot of time setting up their development environment?), but I think the tinkering is key. Kids who are simply content to tinker with what is provided will stay at that level; the ones who are truly interested in going beyond that stage will begin asking questions and driving beyond what has been provided.
The beginning of my own path to being a programmer, long ago, was playing with games made in RPG Maker 95. If I didn't understand how to pass an obstacle, I would "cheat" by opening the game's world-database file up in the game editor, finding the "object" with the logic that was inhibiting my progress, and then modifying it to allow me to bypass it.
After that, I progressed to just opening games in the editor to "figure out what the author actually wanted me to do here" so I could go back to the game and do it; and then, finally, just observing how people had constructed their games.
All in all, it felt very natural to transition from there, to making my own games in the editor.
I think it was a (probably unintentional) brilliance on the part of the company who produced the software, that the games produced only by using the "hardcoded" features of the game-editor were so simplistic and limited--while also allowing a complete, Turing-complete scripting capability. It meant that, very quickly after starting down a path saying "I want to make a game", I was forcing myself to learn programming concepts in order to extend the engine with the features I wanted in a game.
After a while of doing that, I had absorbed enough about programming to understand that the game-editor tool itself wasn't "magical", and that the whole of its hardcoded game engine could be represented with a not-overwhelmingly-large piece of the same scripting-language logic I had already been writing.
After that moment, it just felt "natural" to move on to reading some Javascript tutorials online, and to pick up a book on C.
The realization that there was no magic in the software I interacted with, but instead merely sequences of small, logical steps I could identify and replicate myself, using a library of atomic mechanisms (branches, loops, etc.) specified to a computer in a formal language: I think that is the one thing that needs to be captured by anything that claims to "teach programming."
And, personally, if I were going to teach programming, I'd try to do it just as I did above: give them completed game, but an overly-difficult one, one which they aren't just modifying for the sake of modifying, but modifying because that's what will let them win.
And, at first, I don't think "programming" even needs to be introduced. Just introduce the framework, the idea of modifying an existing interactive thing (don't call it a program), even if it's just by opening a visual editor and erasing a rock that's in your way.
Then, in later exercises, you can make the "thing that's in your way" much less simple--a sprite whose state is wrong, an event that won't trigger until a flag is set from somewhere else, a person who expects some variable to hold an impossible value where you have to construct the trigger to set that variable yourself; etc.
Eventually (but probably within one semester of an after-school-club setup!), this "adversarial modification framework" could work up to the point of something like Core Wars, where the student is writing writing complex agentive processes controlling shield drones to protect the player-character from enemy fire as they move toward a goal.
From there, you've got a decent jumping-off-point to the "wanting to mod the engine to get it to do the cool things other people have made it do" phase, and from there to the "why not just write it all myself?" phase.
Some other thing could be Scratch/Kara, but I'm not sure if it exists in english and personally I don't like it.
Perhaps something to explore as a platform as well as it's not too expensive and comes with what you need to hack around.
It comes with Minecraft Py installed and has a few tasks to customize a level, character, etc. Python dev tools comes installed as well as Scratch and other exercises.
The idea of gamifying tasks across the platform is interesting especially if you think of a class of folks and a leaderboard or something - maybe not something to stress but some folks like competition more than others to drive them to learn.
https://kano.me/store/us/products/kano-complete
Lately I've reset the learning process focusing more on basics (networking, files, processes, utilities, etc) rather than programming.
I've been working indirectly with school districts doing this for a couple years now, and have seen great results from curriculum very similar to this -- https://code.org/educate/curriculum/elementary-school#overvi...
There are other courses for different ages, too. Not sure what age groups you are looking at...
Once they know computational thought, THEN teach them how to code for an app.
Another project was using arduinos -- and I even got them writing C, which more or less worked. You didn't need too much code to blink a light and they loved that. The mix of coding and the hands-on wiring up their breadboards kept it engaging. We did a little project where the light blinked with a frequency related to a temperature sensor, so when you put your finger on it, it would blink faster. One kid had the grand idea of having it blink faster when cooler and slower when warmer, and watching him figure out the math was great.
For younger kids maybe a block-programming interface would be good: https://developers.google.com/blockly/ || https://snap.berkeley.edu/ || https://scratch.mit.edu/
For a less high-tech approach, you should look at http://csunplugged.org/ , e.g., http://csunplugged.org/binary-numbers/
In all cases I think the instruction/teaching is going to be key—through the physical presence and support. It will be comparatively more difficult to bootstrap and get them to learn by themselves. Peer tutoring is very promising though: See: https://www.youtube.com/watch?v=dk60sYrU2RU and https://www.youtube.com/watch?v=y3jYVe1RGaU
It would be great if you write a blog post about this and what worked so people can follow in your footsteps. Good luck!
At first, I thought it was silly to teach "drag & drop" programming and would have preferred a high-level scripting language. But, after teaching 2 semesters of Snap and observing classes in Java, I'm a huge fan.
2 main reasons:
1. Time-to-cool-result is really low. The first project was a Mario-like game. Less than 10 hours from "never programmed" to "built Mario game" is a really powerful first experience. (Demo: http://snap.berkeley.edu/snapsource/snap.html#present:Userna...)
2. Syntax and compiler errors are really confusing. When I walked around the Java class, most kids were asking questions about how to fix their syntax errors. In my class, most of the questions were conceptual.
It's easier to go back and learn a "real" language after you understand the high-level concepts and have seen how cool programming is.
If you want the resources I used, feel free to ping me (adamaflynn@gmail.com).
http://www.bootstrapworld.org/
Bootstrap 1 is computing tied to algebra concepts, targeted at the middle school age group (US grade 6-8). Students learn things like order of operations and what a function is while building up their own game. The curriculum has lots of activities that show students how to use code to generate images early on, which gives something immediately interesting and tangible to work with.
It runs in a stock browser (lots of students do Bootstrap on inexpensive Chromebook models), has a great support mailing list, and is used in schools across the US already. It also explicitly helps with math skills, which can be doubly useful in preparing for other STEM topics in the future.
https://www.youtube.com/watch?v=leBEFaVHllE&t=89s
was a pretty smart way to start out. Its possibly the opposite of what you want as it is completely unrelated to tools/manuals/etc.
You can also get things up and running really quickly with LOVE2d and Lua. love2d.org
One thing that we always did towards the beginning of a class was an exercise where we tell them to write down the steps to make a peanut butter and jelly sandwich. Then we'd literally get bread, peanut butter, and jelly, and follow their instructions to the letter. No one ever adequately describes the process: "put peanut butter on bread" - With what? the jar is closed, I can't! etc.
You might argue this introduces too imperative a thought process - but it gets the "computers do exactly what you tell them to" idea across very well.
Sounds like the perfect introduction to abstraction and wishful-thinking guided programming! (Maybe not using big words like abstraction for kids)
We needed to describe how to draw some sheet music on the chalkboard, but you couldn't gesture (we could only communicate through an imaginary phone line), and he would take whatever you said as literally as possible and opposite of your original intention as he could.
"Ok, draw 5 lines" (Draws 5 squiggles) "No! 5 straight lines" (draws 5 lines in various locations and directions) "Nooo! 5 straight lines, above each other, horizontal!" (Draws the 5 lines of a musical staff, but 2 inches long and 3 feet vertical spacing between each line). "Nooooo! 5 straight lines, above each other, horizontal, they should be very long and close together" (Takes out a piece of paper from his desk, draws the staff on it) "NOOOO! On the chalkboard!" etc
Bootstrap World (http://www.bootstrapworld.org/) is a curriculum for teaching CS and Algebra while making a simple graphical video game using Racket (similar to Scheme). You can do the exercises using Dr. Racket IDE or by using a web-based IDE (http://www.wescheme.org/).
You also might take a look at Picturing Programs (http://picturingprograms.com/) and How to Design Programs (http://www.htdp.org/). Both of those may be more advanced than what you would want to start with, but they are both focused on teaching computer science concepts more than the particular language and both are aimed at beginners without any background with code.
We run an after school classes program in Barcelona, Spain. Where we teach kids from age 4-15 "programming" or computational thinking.
Depending on age group there are different tools, and starting with the really young ones, we use tools like Hopscotch and other simpler coding apps, when we use technology. And even more fun is to learn about coding not even using any tech. So then we revert to using pen/paper/strings and ourselves, programming each other is a fun thing to do, and you can debug the code in group, and learn to understand how computer operates, and how to give orders.
Once the kids get slightly older, we use to go straight to scratch, (this is the first stop we tend to go to regardless of age if anyone is new, just to grasp concepts) This will not take to long if the kids are older than 10.
But even from 6 years of age we've seen enormous potential in using scratch, kids love it, it's visual in the output, super versatile in what you can do (we get blown away by the kids all the time). And you can indeed build very complex things with scratch, as well as you can produce a pong game in matter of minutes.
Main take away, if you want the kids engaged, get them super comfortable in Scratch, and get them to understand problem solving using computational thinking, rather than go straight to the browser and manipulate the DOM, that's not learning kids how to code, thats like peeking and changing values, not really getting to the core of programming.
Once the kids are comfortable in understanding that one thing can be solved in more than 10 ways, and that no real way is the right way (except if it is). Than make an introduction to text based programming, either looking inside scratch code, or by looking at something in the visual spectrum, like processing, this is a great first step and good jump from scratch. And it's easy to build on top of this and move into javascript.
When I'm mentioning age groups it's only if they have zero prior knowledge about coding, we have 6 years old that program as good as 12 years old but the 6 year old kids have been doing it for a year or more and the 12 year olds are just a couple of weeks into classes.
So it's also about checking the temperature on knowledge. Once you start moving up the ladder on text based programming, it's important to understand how to keep the vast majority interested, and not just the .consoleLog(); persons interested. Keep in mind that programming comes in many shades, and not everyone is hard core math nerd loving, but still can be terrific problem solvers, if given the right tools to do so.
I would say the biggest take-away for us since starting KidsHackClub.com is that make sure it's fun, do not indulge in long demos, or make complex things, and show of big projects, it wont get the kids into coding, it will scare them away. So start small, and build up as time goes, and make things that are visual, no-one enjoys staring at lines of intigers counting in the console, sorry peps, it's kids from the touch generation, they have played with phones and tablets since they where born.
Would love to chat more, just hit me up on twitter @LinusEkenstam or @KidsHackClub and we can also do email, but ping me on Twitter and we can hook up.