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!

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.

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.

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.