“Can we make Karel shoot things?”
“Can we change what Karel looks like?”
“Where is that letter on the keyboard?”
My first class teaching iOS wasn’t going quite as I had planned.
A few weeks earlier, I had responded to a Craigslist ad to teach programming to gifted 4th graders.
I was, of course, skeptical.
There have been a number of successful young app developers; one twelve-year-old even gave a TED talk because he created an app. The startup MakeGamesWith.Us advertises, “It’s so easy we got high school students to do it.” New initiatives, like CodeHS, provide an online platform to teach young students how to code. But these stories, increasingly common, have parents, teachers, and students thinking, “Why not me? Why not my kids? Why not younger?”
I convinced myself that there was no harm in trying. If getting the kids excited was a primary goal, it would be hard to do much better than having them build an app.
The First Class
For the first class, I wrote a port of Karel the Robot to iOS. After the first twenty minutes of the hour-long class were spent logging into the computers, downloading the starter project from github, figuring out where it downloaded to and opening XCode, I had them run the example. I opted for an exploratory introduction, starting without code: using the four buttons in the app, try to make a T out of beepers.
After about five minutes of trying to get me to tell them how to do it, they were all able to figure it out within about three minutes. Then things got interesting. I told them that if they just wrote the code in the buttons into the ‘run’ section of the SuperKarelViewController.m file, Karel would do whatever they commanded automatically.
After another short lesson on how to navigate the tree-like file directory on the left of XCode, all but one was able to open the file. But as soon as the first error came up, we were detoured.
“Can we change what Karel looks like?” I was excited that they brought this up, and half disappointed that I hadn’t thought of it myself. Lots of research has shown that something as simple as having a customized avatar increases engagement drastically. “Sure, just replace the karel.png file,” I said.
After explaining how to download pictures from the Internet (including how to control-click on a mac), drag (it’s far more efficient, albeit not as entertaining, to use one finger to hold down the trackpad button and use another finger to drag across than to press one finger down really hard and simultaneously drag it across), rename files, and navigate the file system, they were able to change the image of Karel.
Once the students were able to comprehend the difference between parentheses ( ), square brackets [ ], curly braces { }, and where to find them on the keyboard, half of the red exclamation marks went away.
After more running around the room, explaining the difference between “[self putBeeper];” and “put beeper”, and pointing out a couple dozen spelling and capitalization errors , the rest of the exclamation marks went away. Most of the class had a runnable program.
One student asked how we could make a command for turnLeft, since we could only say turnRight, which was annoying. Two exceptionally bright girls stayed after class, and I taught them how to create helper methods. When they finally left, a half hour later, they had probably written a couple hundred lines of code between the two of them, drawing with Karel like pros.
But when they didn’t want to leave, I noticed what would become perhaps the single greatest problem. They had to put back the school’s computers into a cart without a way to see their work again or show it off at home. The next week they would come back to class and remember what? Time would tell.
Learning by Debugging?
Within hours of the class ending, I received an email from a mother saying that her kid was struggling to understand how everything worked. My first thought: perfect, that’s what real programming is, and it’ll be good for them to struggle. But on second thought, I figured maybe I should balance the exploratory nature of the first class with a more structured, explanatory approach. So in the second class, I typed up in the comments of the file, an introduction to programming, and we read through it a line at a time:
This is what a comment is.
Every left parenthesis ‘(‘ needs to end with a right parenthesis ‘)’.
Every statement ends with a semicolon.
This is the syntax (define syntax) to define a method.
We defined helper methods so that it would be easier to write more complicated programs. Again, something as simple as the following method had lots of pitfalls.
– (void) turnAround {
[self turnRight];
[self turnRight];
}
Lots of people struggled with ( ) vs [ ] vs { }, capitalization, remembering where spaces were or were not permitted, and when the order mattered.
Even at the end of the course, none of the students would remember this syntax. But this exercise taught me a lot about my students. Even among these gifted students with roughly the same experience coming in, some had practically finished the assignment by the time others were able to download the starter code and open the file. I could also feel that I was losing some of the students’ interest with the unexciting lesson. And Karel still couldn’t shoot anything.
Blended Development
The third week, I turned to a new approach, one that, for better or worse, I would stick with for the rest of the course. Inspired by Zed Shaw’s Learn X the Hard Way series and Khan Academy’s flipped classroom model, I typed up and printed out a set of explicit instructions (including the code they were to type out) that I handed out to each student to follow asynchronously rather than trying to teach a single lesson synchronously to an entire class. Then, I could spend my time (literally) running from student to student helping them fix their bugs.
There were problems with this approach, of course. My instructions weren’t perfect. Students, while waiting for me to come help them, switched to “temporarily” playing video games in the mean time. But more importantly, in hindsight:
- The culture of everyone being in this together collapsed.
- They weren’t that good at following the instructions.
A discussion of the former is beyond the scope of this particular post, one that I still need more time to think about (and one that, having taken many Coursera classes at Stanford, I see as a problem even at the college level in large lecture classes).
The latter was particularly disturbing because programming, at its most basic level, is giving and following instructions. When a student asked “What do I do next” and I responded, “Go to the next step,” and then the student asked five minutes later, “Why isn’t it working?” and I responded, “Oh, you skipped step 3,” I wish I could say I was surprised. But honestly, that’s what I was like at that age. Teachers used to give fake quizzes about following the instructions where the first instruction is “read all the instructions before you start” and the last instruction is “if you’ve read this don’t do any of the quiz.” I was one of the 90% that did the entire quiz because I didn’t read the instructions.
Pragmatic Programming for Young Pupils
By the end of the third week, in which I introduced user interaction and storyboards, I was beginning to doubt whether teaching iOS to fourth graders was a good idea at all. I strongly considered switching to Javascript or Processing, but figured it would just confuse the students more. I decided to let concrete skills take a backseat to two higher level goals for all my future course decisions:
- Programming “intuition”.
- Programming excitement.
If they actually learned the concepts and skills of functions, if-statements, and for-loops, that would be a plus. I wanted to take advantage of their young age to give them a new dimension to their lives.
Elementary school pianists, when they’re learning a Bach invention, have the intuition to get louder when the notes get higher, even though there’s no dynamic marking. Middle schoolers, when they’re watching football and see a flag on a long run have the intuition to say “offensive holding” even if they didn’t see the penalty. I wanted my young programmers, when faced with something going wrong--not just in their code but in their lives--to think “oh, let’s logically trace this back to where it first started.”
The second goal, excitement, is self-explanatory, but I decided it was time to move on from Karel once every other question became “how can we make Karel shoot something,” and I sadly responded, “that’s a little too complicated for the class right now, but you can try to figure it out on your own if you want.”
Racing to the Finish Line
In week four, we created Tic Tac Toe, starting the project from scratch. Some students unexpectedly got better. Others started to give up. Kids got busy and started to attend class sporadically. With at least a week, and often two, between sessions, I wrote all the instructions with the assumption that they forgot all the previous programming concepts that we learned.
In weeks five and six, we created a simple calculator program that converted celsius to fahrenheit, calculated absolute value, and for the two students that got it, iteratively calculated a factorial. One student explained to his mother, in detail, the difference between an int and a double, and how an if statement worked.
In weeks seven and eight, upon a student’s request, we created a break the targets / pop the bubbles program. Our most complicated program to date, this involved laying out the main view programmatically. Even though there was a fair amount of code I had to give to them that they didn't quite grasp, they were definitely getting a hang for the more basic material, and they were debugging syntax errors on their own now. Much of the class finished this assignment completely.
In week nine, we created a quiz game that used multiple screens. Heavily based on the storyboards, this was one of the most successful projects. The students had practically mastered the XCode interface. Even if they didn't always get the code, they were experts at learning to use new applications.
In week ten, we created a guess the number game. Students both followed the instructions to the T and they demonstrated excellent debugging skills. Whereas in week 1, I was literally running around the room to diagnose every single error, my students could now fix a great number of the errors that they had seen before -- from unbalanced braces to forgotten semicolons to the occassional undefined variable.
By the end, my students had:
-become much better at following instructions, likely just by virtue of repetition
-learned the XCode programming environment, especially how to use storyboards, incredibly quickly and effectively
-learned the high level, repetitive concepts: semi-colons, open and closed brackets, the connection between the code and the interface, how everything has to be done explicitly
-a basic understanding of methods as commands
-an appreciation of how hard even simple tasks can be
-an appreciation of how rewarding it is when your code works
-an understanding of what it means to do programming
-an intuition of how to read error messages and debugging
-learned that “view” is spelled with i before e
On the other hand...
-They didn’t know how to design a program by themselves without instructions
-They couldn’t write an if statement or call a method without something to copy
-There was still a ton of magic in the syntax. (what’s that * for after NSString?)
These were, I suppose, trade-offs that I consciously made. I don’t know yet if they were necessary, and I don’t know yet if they were smart. Conclusions and the story of teaching python to 7th graders are coming soon. Let me know if you'd like copies of any of the assignments, or to discuss further!
