 |
Once we have a room full of kids, what should we teach them?
Posted by sonyabarry on April 21, 2008 at 11:33 AM | Comments (10)
In my first post about CS education I talked a little bit about what kind of infrastructure we need to do a corporate backed computer science education program for middle or high school kids. In this post I'd like to address two other important issues. The first is Which kids are we aiming these programs for? and the second is What do we teach them when they show up?
There are three general classifications I use for kids in this age group:
1. Geeks. These are the kids who are probably a lot like you were. Usually male. Usually hooked on computers and curious about how they work from the first moment they saw them. Interested enough to pursue CS topics and programming on their own because they enjoy it as a hobby, and a way to tweak their games.
2. Average kids. These are most of the kids, male and female, who like the web, are comfortable with the machines, but don't regard them with any more interest than your average motorist regards their car. This group also includes the group of kids who, due to social or financial circumstances, haven't yet sat down at a computer for any reason. There are a lot more of these kids in the U.S than you might think.
3. Everybody else. These are the few who either have no aptitude at all or absolutely no interest in using computers beyond what is required for class, and they really wish they didn't have to use them in class either. They don't use them at home, even if they have access. Their numbers are small, but they do exist.
So which group of kids should we be aiming for with an after school program? I vote for group 2. The truth is, anything presented to the whole school will grab group 1's attention, but they may be more advanced already than anything we're going to show them. We should be doing something to support group 1's ambitions and interest directly (more on them in later blogs), but those are the kids who are already pursuing CS, who are looking forward to programming classes in school and beg their parents to send them off to computer camp in the summer. These are the kids who, like you, are going to turn into the software engineers of the future. They are already on the path.
CS enrollments are falling across the board. Why? Because we ignore group 2. This is the potential group that could fill out those classes if they are exposed in the right way, and at the right time. They might be more interested if they understood how creative CS can be, and if they realized that despite the media reports to the contrary, there are good jobs with great pay available in the US. These are the girls who, like me, have an aptitude but aren't interested in tearing computers apart as a hobby and so they think CS wouldn't be interesting to them.
These are the kids who we need to be paying attention to. These are the kids that I want the opportunity to hire when they graduate from college ten years from now.
So, what do we teach them? This is a really tough call. There is so much to cover. In my own classroom I made the decision that at middle school age, it's a lot more important that a kid walks away from the class with the feeling that they enjoyed it and that they can do it than it is that they remember the relationships between classes and objects or the ins and outs of for loops. In young kids, confidence trumps everything.
I think it can be argued that the same thing should happen with high school students who are given CS as an after school project rather than a regular class. More than anything we need these kids to be open to the possibility when they get to college.
We also need to do something else that often gets lost in the shuffle - we need to prepare them for things they're really going to see in college.
Here's an anecdote - I was TA for a first semester Java programming class while I was in grad school. I had a student who came in as a freshman completely excited about the class. She had "majored in computers" at her high school and was ready to go. She had a great attitude, certainly had the aptitude for it, but she dropped out of the class and changed majors about six weeks in. Why? Her computer class in high school had been all about using Microsoft Office products at the expert level and a few WYSIWYG web page projects.
She came in confident, but she was confident about the wrong thing, and she was crushed. She's now a chemist. She's an extreme example, but I doubt she's the only one who has had this kind of experience.
My approach to solving that problem is to make the first things my kids see is a minimal IDE (we use JEdit) and compiling from the command line. This gives them a couple of advantages. First, they're never going to be taken by surprise later on when somebody else asks them to work that way. Second, getting familiar with the command line and navigating the file system that way helps them understand their computers beyond the GUI level. Once they realize there is more than what's at the surface, they are naturally curious.
I chose to go with an applet that uses the Graphics API for my first lessons. The reasons are simple - a kid can grasp quite easily what drawLine() or drawOval() is supposed to do. I give them a few lessons and assignments that guide their analysis of their programs, and then have them use what they've learned to write an applet that has a smiley face picture. It's engaging and creative, and the kids get it immediately. They learn about methods and parameters, they get some good practice at doing the arithmetic to get all the pieces place properly, and they learn about logic bugs and order of execution.
The next thing I do with them is design a GUI guess-my-number game using Swing. It introduces loops, decision making, the % operator, integer arithmetic, and random number generation as well as more complex code using the ActionListener interface to handle buttons and text input.
This is when I run out of time with them. It usually takes about 20 hours of instruction, with plenty of CS related digression to get this far. If I had more time, at this point I'd introduce them to Greenfoot or Alice.org. My point is always to give them the basics, and then show them the really cool stuff once they have the basics down.
With the specific goals of getting kids interested and confident, what would you want to show them?
Bookmark blog post:  del.icio.us  Digg  DZone  Furl  Reddit
Comments
Comments are listed in date ascending order (oldest first) | Post Comment
-
You may need to separate the true geeks from the ones who are more artistically inclined. There is so much to do in CS these days. People could specialize in web design, graphics design or backend programming. The various languages for programming also provide huge options. Every kid will have an aptitude for and interest in maybe one or a few aspects of CS.
Posted by: j_hell on April 22, 2008 at 03:49 AM
-
You start with a command line compiler? Really? In 15 years of commercial software development, I've only had to use a command line compiler a handful of times. A couple of years ago, a friend of mine (a math teacher, not a computer guy) taught a high school Java class, and said that using the command line compiler was the most difficult concept to teach the kids.
Posted by: tcbinjon on April 22, 2008 at 06:24 AM
-
I really do start with the command line. It's not difficult. It takes about half an hour to give them a tour of the file system from the command line point of view. I have them navigate around using their mouse side by side with cd and dir so that they can make the connection between how the two work.
I have not had a single student come into my classroom knowing ahead of time that the command line existed. They actually think it's pretty cool.
The point is that I want to separate the programming from an IDE, and I want them prepared for whatever they're going to see later in school down the line.
My own experience shaped this idea. Most people I know with degrees or careers in CS grew up with computers, playing with them, tearing them apart, or wanting to learn how to program so they could write or tweak their games.
I'm 36. I finished my undegrad degree in '94 by writing all my papers on a Brother electric typewriter. My first computer was a Gateway laptop and had Windows 95 on it. I came late to the game and even though I'd been using some serious software for years by the time I took my first programming class at a junior college. I was LOST in that class. Every teacher I ever had made the class more difficult for students like me by not explaining the most basic concepts of how to get the thing to go, even in introductory classes where that should be necessary. Too often college courses assume some prior knowledge even if they don't explicitly require it. Every teacher who makes that mistake loses potential students out of frustration.
Also, in my experience, teaching the overhead of an IDE is a lot more difficult than the command line. NetBeans and Eclipse (and even BlueJay) are awesome tools, but I prefer to start without them.
So, yeah, it's a small pain to teach them about the command line, but they're never going to have to do anything more difficult than that to get started in any class down the line. They can even tell their friends years from now about that crazy middle school teacher they had who made them do the computer equivalent of walking backwards to school barefoot in the snow. I don't mind that at all if it means they can walk into a classroom down the line feeling like the most experienced student in the room.
Posted by: sonyabarry on April 22, 2008 at 07:20 AM
-
We've run computer clubs for high school students in which they learn J2ME game programming on mobile phones. Many kids are gamers and virtually all of them seem to own and rely on mobiles these days, so this turns out to be highly motivating!
Posted by: nickefford on April 22, 2008 at 09:15 AM
-
Heard an interesting podcast about C++ recently (95% it was the one linked below.) Amidst the general discussion there was a challenge to the received wisdom on how C++ is taught. Basic concepts like pointers tend to be taught first, the standard lib is discussed later, while templates are left until last or held over for an 'advanced' course. The interviewee commented that ideally templates and the standard libs should be taught up front along side the basic language syntax, while pointers should be left towards the end.
http://www.se-radio.net/podcast/2008-03/episode-91-kevlin-henney-c
Rather than trying to give them an introduction to professional software programming, from the nuts and bolts up, why not just let the kids have fun with a high level application?
For example: suppose you allowed the students to program bots which would compete in a virtual world? They write a class implementing a 'Bot' interface -- effectively providing the brains of the bot -- while you write the backbone code which provides the simulated arena in which the bots 'fight' (or race, or solve a maze...) Stealing a leaf from console games like "Metal Gear Acid (2)" each turn the bot can make two or three actions -- move, scan the area, plant a trap, fire their laser, etc. -- with each action incurring a cost which determines how long they have to wait before their turn comes around again. So first lesson would get the bots moving around by manipulating X/Y variables. And by the last lesson they're using arrays and lists to remember/navigate the walls of the arena and where they planted traps, tracking their competitor bots, etc...
The more practice they put into their coding, the better their bot gets at winning each competition. It's a nice way of turning software engineering into a game, where coming up with crafty algorithms to beat the opposition is the goal -- a kind of arms race which encourages them to continue learning.
Games like the above have been around in the programming community for a while, mainly for showing off advanced coding skills, not teaching.
Posted by: javakiddy on April 22, 2008 at 09:20 AM
-
I'm with you on including the low-level aspects such as command-line operation. I'm sick of interviewing (and rejecting) candidates who don't understand how something works, but instead have blundered through their career with blind faith in a certain tool or procedure.
High-level abstractions are great as long as things are working as expected. Which is pretty much never. Then what do you do? To be able to fix a problem, you have to understand what's under the hood. Sometimes that means knowing when to use -verbose option to javac.
One's success and utility are going to be limited by the lack of innate curiosity that drives one to discover what's happening on the command-line, at the kernel, and in the registers.
Posted by: erickson on April 22, 2008 at 12:56 PM
-
erickson: I'm with you on including the low-level aspects such as command-line operation. I'm sick of interviewing (and rejecting) candidates who don't understand how something works, [...]
To be fair though, how many middle school children do you interview?
As someone who came up through the nut-n-bolts school of programming (there was no other way back in the 8 bit days) I've become increasingly suspicious that this approach. I think it frightens away more kids than it encourages. For those who choose to follow CompSci at a higher level there's time to learn the command line etc. For a course which is supposed to be selling CompSci to kids one should surely promote software engineering as a fun, challenging, and satisfying endeavour?
Posted by: javakiddy on April 23, 2008 at 03:19 AM
-
javakiddy: ...promote software engineering as a fun, challenging, and satisfying endeavour?
That's exactly what I'm going for with my classes. Even though we're compiling from the command line, the very first program they do is an applet that uses drawLine(). That's it. They can immediately see what it does and immediately ask for other shapes to draw with. The first big thing that they do themselves is to make a smiley face on their applets. It's not nearly as fancy as robots, but it's creative and engaging, and all the proof I need of that is the general dismay in the room when we have to end class for the day and they want to keep tweaking.
As any parent who has watched a kid open a new toy and then proceed to ignore the toy in favor of playing with the box it came in knows, if you can engage creativity, you've done the hard part. It doesn't have to be expensive and flashy.
Robots are cool, and projects like those would certainly keep kids engaged. But who's going to pay for them? The few programs of that sort that exist in high schools are successfully catering to the geek kids who are already on track to become engineers anyway. They are great, but they really only reach upper middle class to wealthy white boys in the US. That's a demographic reality.
We need to cast the net wider, and to do that we need to be able to grab some attention in a more cost effective and portable way. If we fail to cast that net wider, university computer science programs will continue to shrink, and the pool of candidates we have to hire would continue to only include the same types of geeks who are already in industry, and not enough of them to sustain and grow the industry going forward. There's your economic reality.
Posted by: sonyabarry on April 23, 2008 at 09:29 AM
-
Robots are cool, and projects like those would certainly keep kids engaged. But who's going to pay for them?
They're not real robots. They're just graphics in a video game. :)
Posted by: javakiddy on April 24, 2008 at 07:06 AM
-
I should add that I broadly agree with what you're saying, just in case there's any misunderstanding. Flashy isn't necessary, and is just a waste of money. Imagination is where it's at. The example game I gave is basically a kind of Chess like affair, with little robot icons moving and acting on a screen -- you write the framework and they write the 'brain' (via an interface) which controls a 'robot' on the screen. Periodically you plug their brain classes into the framework to run a sample game, and find out who's brain is the best at winning, or solving, or co-operating, or whatever the task is. You write the dull part of the software, so they can focus on the fun part alone.
Remember, the genius of Lego was that it allowed kids to explore the fun of model building, without the learning curve of working with wood and tools... Kids who got seriously inspired by Lego then progressed to the more traditional techniques. :)
Posted by: javakiddy on April 24, 2008 at 07:44 AM
|
java.net RSS Feeds
