Get SET, a program for introducing high school girls to science and technology. I helped with the Java programming workshop. This was my first time with Get SET (or any similar program), but I was impressed: it's a good program, and I want to do more work with them.
The workshop went really well, better than I expected. The girls were all bright and motivated, and they all managed to complete all the programming exercises. At the end we talked about open source a little bit (I was glad I'd brought the linux laptop along).
Some of the girls found out they don't have the patience needed for programming or debugging, which is fine -- not everyone is interested in wrestling with obscure compiler error messages. Others dove right in, and freelanced a little, changing "Hello world" strings to messages talking about themselves or their friends.
The girls who had the most difficulty apparently struggled either due to poor typing skills, or, perhaps, poor vision. I saw a lot of girls typing colons instead of semicolons, or periods instead of commas, or 0 or O instead of (), and of course the compiler error messages didn't give a first-time programmer much clue that that was what the real error was.
The only criticism I had was that it was a little too "cookbook". Mostly they were given the code, and had only to type it in. Since there were lots of exercises and everyone was working at different rates, any theory presented in front of the class was likely either ahead of or behind the exercise that any given girl was working on at the time.
This is a difficult problem to solve. Having lots of small exercises, where everyone progresses at her own pace, works out really well; but not being able to explain theory means that a lot of the girls were just blindly retyping, and didn't understand things like curly braces (I saw a lot of compiler error messages caused by "import" statements inside a class, or statements outside any class method, or simple unbalanced braces).
I wondered, during our postmortem after the girls left, whether it might be better, rather than having the girls complete 13 exercises then work on some extra tasks if they have time, instead having some extra tasks which they could complete at the end of each exercise, so the fast-working (or fast typing) girls would have something interesting to do while the others caught up, but everyone would still be on the same exercise and then the instructor could explain the next one to everyone all at once.
This would of course require more prep work, coming up with interesting extras for each exercise.
They used Codewarrior for the exercises, and it took a lot of mouse clicks to change from one source file to another, and it has to be changed in two places. A lot of girls ran into trouble there. I found myself musing on how much easier it is just to type "javac filename" and then "java filename" to run it. (I'm sure Codewarrior is fine when you have a full project already set up and you're used to the interface.) Besides, javac (either from Sun or IBM) is free and Codewarrior isn't, so if any of the girls are interested in following up, which one would be easier for them to use themselves?
The last exercise actually did use javac, though, and it turned out that the software had been installed to an unexpected place, and so the pathnames in the instructions ended up not being right. I don't know what the procedure is for having software installed on lab machines at a school, nor whether there's much chance to test the setup before it gets used for the actual class. It sounds like a fairly complicated thing to coordinate. Of course I found myself thinking about whether customized knoppix CDs could be used for such a purpose (though they would probably be too slow).
If I ever get to design a course like this, I might try less "printing to stdout" and introduce GUIs earlier. GUIs are harder to program, but there was so much provided code anyway that it might not hurt to just provide a framework and say "This is how you bring up a window; don't worry too much about the details" and then start introducing buttons and text fields and so on -- rather like the approach taken in the O'Reilly X and Motif books, starting with a small "hello world window" example then gradually adding things to it. I think building up a medium sized program, with a window with lots of elements in it, might be more fun for a beginning programmer than just doing one short program after another.
The girls could have used some sort of help interpreting the compiler error messages, but I don't know of a good solution to how to teach this. Compiler errors tend to use fairly technical programming terms, which wouldn't have been appropriate to try to explain to someone with a few hours' programming experience. Even some of the volunteers had trouble figuring out the error messages. I wish there were a language for which this wasn't true, but python, perl, JS, all have fairly esoteric error messages which are difficult for a beginner (and sometimes even an experienced programmer!) to understand. The only clue I can think which might have helped them is a rule such as "if the compiler gives you an error you don't understand, carefully check the line with the error and a few lines for typos or incorrect punctuation marks." Perhaps followed by rule 2, "If that doesn't solve it, or especially if the error seems to have nothing to do with the line where the error is reported, check everywhere for balanced parentheses, curly braces, and square brackets." Those two would have handled at least 80% of the errors I saw.
Finally, the big question: how do you make the process creative, starting with students who have never programmed before? Learning is much more fun when you have problems to solve, or if you can look at it as a friendly competition or a game. That's hard when you're trying to cover a lot of new technical material in a single day. I don't have any ideas yet, but I'm going to give it some thought.
[ 13:40 Aug 14, 2004 More education | permalink to this entry | comments ]