For the past 5 years or so, I've been spending my summers teaching kids how to program, build robots, make websites, videogames, etc.
I usually teach algorithms without using a computer as well. I put kids in groups, and give them a shuffled deck of cards. How can we sort it as fast as possible? Can they come up with their own techniques? Then we have little challenges to see which group sorts it the fastest, and they explain their "algorithm" to the others.
It's an intuitive way to introduce many concepts (including parallelism, yay) without using a computer. I think it's critical to show that this elegance in computing transcends the machine.
I'm currently doing pretty much the same thing as volunteer work. Would you mind expanding more on the methods you use?
My kids are in ages 8-12. One big problem is that I must find a way to have them work and explore on their own, but most of the tutorials and documentation that I know is good and up-to-date, is in the English language (and I'm Dutch, as are the kids). At that age they really can't yet read English very well.
Of course the best solution to that problem is to spend some more time and try to find good Dutch HTML tutorials. They should be out there, it's just that my Internet bubble seems to be a bit anglo-centric :) Also if Python was invented by a Dutch guy, there should be some quality Dutch language material written on it, no?
But apart from that, I also wonder if there's some other ways that do not involve reading manuals. While the cards thing seems interesting, I wonder whether the kids would be excited about it, it's not a school, they go there after school and are offered the opportunity to work on all sorts of technical projects with our guidance (there's also an electronics lab where they get to solder resistors and diodes and such to make flashing LEDs etc).
I'm kind of looking at how the more "crafts" like departments have it easier (apart from electronics, there's wood, metal working, clay/pottery and more). There, the teacher can just show how to do something and explain, multiple kids can watch and then try it themselves. With the computers it's like they can't do very much or explore new things without me explaining them one-on-one. Which takes way too much time and also isn't really the best way to facilitate the "exploration" aspect (which is one of our goals).
So I sort of know where the problems are, but I'm kind of stumped on how to fix them. Except for taking the time out to write tutorials (and perhaps some screencasts) myself.
You should see whether you can get a copy of RoboRally in Dutch, or at least in German if that would work. If not, consider translating the cards, each of which has an arrow and a direction, such as "turn left", "back up", or "move forward 3".
I'm really happy that my class has gotten all of you excited about this and thank you all for your great comments. You guys have inspired me to keep going. I'm planning more classes with more advanced topics. Whenever I have something fresh I post it on my facebook page www.facebook.com/drtechniko. I would love for you guys to get the conversation going on there as well.
The whole class was about an hour. However, I spent about 20 minutes or so playing a different game which would get the kids excited about robots. I showed them some robots that exist today from current research and I actually had a little robot I made, which started walking when you clap. This way I introduced them the concept of a "brain" or computer residing inside the robot so that it would do stuff if you gave it the right instructions.
Well, I have more than 10 years of programming experience, so I obviously did not get the feeling of being taught programming. But I think non-programmers also do not have this feeling. So people play the game, learn to program their robots and maybe don't even realize that this is actual a kind of programming.
I think what people can learn from the game is how to combine simple instructions into more complex robot movement. In addition, you to step through your 'program' in your head in order to check that it is doing what it is supposed to do. But I honestly cannot say if this game is suited to teach programming.
One advantage of the "how to train your robot" activity is that abstraction can occur more than in RoboRally, such as creating repeatable subroutines (eg, turn around then say "I'm dizzy" 100 times).
Awesome idea. I once used the idea of using each kid as an instruction (we had the instructions written on 3 x 5 cards) and did the 'towers of hanoi' problem by lining the kids up and then having them go up, do their instruction and then go to the back of the line.
I agree with Shank though, the idea of being able to drive you parent around is really a great kid hook in this case.
The really awesome part is that there's an element of fun, e.g. controlling your parent, to the whole thing that adds to the experience. If it were a game or something else, it'd have a lot less interest and appeal at that age.
Awesome !
Love that part :
For some reason, kids loved making their parents repeat stuff 100 times over.
It's exactly the kind of thing I used to do when I first tried a programming language (printing random stuff 500 times already feels strangely empowering... not to mention email spamming scripts!). I guess it's one of the main purposes computers were made for.
I couldn't agree more. Whenever I'm learning something, I find that breaking things is the best way to get concepts to sink in. You don't know what a null pointer is until you dereference one.
If I were to teach programming to a class of kids in the 8-16 range, I'd probably get a Python environment up and running and spend:
- Two to five minutes explaining a small concept (start with the print statement, go to variables, then operators, then functions, and so on and so forth)
- A couple of minutes playing around with the concept using some neat functions or classes which you write before the lesson. Like a send_email() function, where you supply each kid with a disposable email address and password.
- Up to an hour repeating the first two steps.
- A few seconds giving them an optional homework assignment which they can work on and show off to their classmates when they come back.
I'm sure they'll be hooked when they find five hundred emails in their inbox, that's certainly the sort of thing that got me hooked back when I first started.
I agree with you on your first point where you say that the best way to get concepts is by breaking things. But two to five minutes for explaining such CS concepts as variables, functions, and even operators may prove to be nothing more than just a fleeting moment, especially if you are dealing with a group.
Do you mean 8-16 as an age range or a number of students in the class?
Also, not all kids get excited at the first sight of scale. It often requires taking time to explain things and give different examples of this phenomenon.
Sorry, I should have been more specific. When I say "explain operators", I mean something along the lines of "To add numbers, you can write '2+5 <enter>' and it will give you 7". In two to five minutes you can probably explain addition, subtraction, multiplication and division and then link it back to variables. So "Type 'i = 3 + 3 <enter>'. Now type 'i <enter>'. It should give you '6'."
It seems to me that attention span is the biggest hurdle. You're unlikely to hold a ten year old's attention for more than a couple of minutes if they don't have a solid understanding of why the concept you are teaching is important and how it ties in to the other concepts they have learnt. If you can show them how useful a concept is, they're probably more likely to go and gain a more thorough understanding on their own.
> Do you mean 8-16 as an age range or a number of students in the class?
Age range. Ideally you would want to avoid having that sort of spread in a single class (perhaps take one class for the 8-12 age range and one for 13-16 age range).
> Also, not all kids get excited at the first sight of scale. It often requires taking time to explain things and give different examples of this phenomenon.
True, I'm just basing what I wrote on what my friends and I found particularly interesting. It's probably different for everyone.
I think this is a critical, and maybe the most fundamental, part of programming. It's not just how well you understand a language, but the entire process of translating what you want to do into a set of instructions.
Once you can do that in a useful and meaningful way the computer just becomes a tool to implement your ideas.
One of my middle school teachers had a lab (which we unfortunately never did) where students had to write a set of instructions for making a peanut butter and jelly sandwich. She would then follow the instructions to the letter and you would discover your errors.
1. Unscrew lid of peanut butter jar
2. Put knife into jar
ERROR: knife cannot enter jar, lid is still on top of jar.
Her goal was teaching how to write the method section of a scientific paper, but I find it far more valuable to teach introductory programming.
This reminds me of a lot of classes where we never touched a computer. Instead we drew our programs on paper and then tried to write the programs to make them on screen.
I am still not sure why everyone should learn programming. Every few days I read about how to learn programming not to mention codecademy and other website. Is it more of a computer literacy thing or is their a huge requirement of auto-didact programmer?
It's easy to fall into that line of thinking if you always see "computer programming" as a single, integrated concept. It's not, although using computers is a great way to teach the actual concepts underlying the exercise.
Fundamentally (and one would hope that this part is made clear to students, teachers, administrators and parents), what is being taught and learned is a method for developing procedures. And I don't mean "procedures" in the context of computation, but procedures in general. I'm talking about the act of dividing a task into its component bits, determining what has to happen in what order, and deciding when things are "done" (whether that's in the sense of being absolutely complete or "close enough for government work").
Those are skills almost everyone needs in life. Programming computers or computer-controlled machines is a great way to learn those skills because of their (to anthropomorphise a bit) literal-mindedness. They aren't going to make assumptions about your desires or correct your meaning. They'll do what you tell them to do if it's at all possible, even if what you told them to do is wrong or stupid, or fail in a most ungraceful way (unless you also taught them to fail gracefully).
We may never reach a point where we need everyone to be able to write software, but we're beyond the point already where we need everybody to be able to give and take instructions.
Many of us are taught music lessons early in life but only some become musicians. The main goal of these lessons is not really for us to become professional musicians in future, but to know that music is composed of notes, who the classical musicians were, what instrument are there, and so forth. The same thing applies to arts and painting classes. The basic goal is for us to get an idea about basic techniques and gifted people.
The main thing to learn is the fact that both music and painting are forms of expression and that we will continually encounter them in life. Also, with the help of these early lessons many uncover their inner genius and that helps them go in the known direction from that point on.
Since coding is an activity that trains one's computational thinking - a skill that is so relevant today - it better be introduced early in life too. It is also a form of expression, and knowing that it exists and how it can be applied is just as relevant as knowing about arithmetic, letters, music, art, etc.
I don't suggest that the format of the current classes is the right one (in fact, I believe that it is not), but it is essential to have a child-friendly methodology and teach coding, or rather "programming", as a skill early in life.
You can easily compare this to literacy, the ability to control written communication. I'm sure around 1800 many people didn't understand the point, since you could always just walk up to almost everyone you'd want to communicate with. There was no way then to forecast all the implications (esp social and technological) that widespread literacy would eventually entail.
Similarly, programming is the ability to control computation. It's very hard for us to understand just how a society would behave when 90% of the population has the power to create any software tool it needs, to compute sophisticated statistics, and so on.
You'd be hard-pressed to find anyone today who disagrees it was a good thing that (almost) everyone learns how to read and write. I'm also convinced 100 years from now, you won't find anyone complaining about widespread programming ability.
How insightful.
I hope we can learn to integrate computer literacy topics gracefully in with other forms of communication (such as math/puzzle solving, writing/composition, the arts, and the sciences) in a way that motivates and interacts synergistically with those other topics, rather than squeezing them out as outmoded forms of only-historical relevance.
I absolutely agree with Nikos' approach to teaching programming young learners without using an actual code. If we teach kids the idea of programming early - it will then be much more intuitive for them to pick up the language formalities later. Because by that time, such a fundamental question as "why" is already answered in practice.
In other words, the time for a real language comes as an actual need that has been experienced in practice and doing. And that makes all the difference in understanding what you need and why.
It's all over the web that more and more parents and teachers come to appreciate the idea of teaching kids to code. But the problem is that they don't know where to even begin or what tools to use. As a result, kids looking to learn programming today are faced with two main extremes:
(1) storytelling, game dev, and animation programs; and
(2) real-world languages or tools based on IDEs;
Programs in the first category are all fine, except for cases when the app is too compute-intensive, or 3D objects are clumsy or rough-looking (but these problems are just temporary).
But those using real-world IDEs to introduce programming are effectively training young pilots on real fighter jets. Such tools seem too complex and intimidating even for experienced computer users. What they really ought to be using is a "flight simulator", but currently there are too few tools that allow to do that and all pretty limited.
Even when we have something that useful it makes absolute sense to use physical games in the gym to introduce the notion of composing instructions for something/someone else (a parent-robot in Nikos' case :)
Nikos, thanks for sharing your work, and congrats on joining Knewton!
Hope you don't mind me including a link to videos of your class once again:
I'm familiar with Scratch as an element of the first category; what other (meta-)programs do you recommend?
I learned some HyperCard and some Basic as a kid, but didn't get hooked until i could do useful things with shell scripting in college, which is definitely a case for category 2, or perhaps something even simpler: programs written in a plain text editor or even just on the command line itself.
The power to do things that matter is typically more motivating to girls than to boys, who will do something just because it's there (ie, why boys tend to play more video games and more girls end up in teaching and social-justice work).
Just trying to provide another perspective. :)
Really great. Thanks for sharing this. It's a terrific way to get parents involved, and a really nice explanation of what programing is. I'm curious about what the next steps would be for kids this age.
I usually teach algorithms without using a computer as well. I put kids in groups, and give them a shuffled deck of cards. How can we sort it as fast as possible? Can they come up with their own techniques? Then we have little challenges to see which group sorts it the fastest, and they explain their "algorithm" to the others.
It's an intuitive way to introduce many concepts (including parallelism, yay) without using a computer. I think it's critical to show that this elegance in computing transcends the machine.