Teaching iOS Development to 4th Graders

The Picturesque Books blog

“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.

* * *

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 a 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 a short lesson on 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.

After a short lesson 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 running around the room, explaning the difference between “[self putBeeper];” and “put beeper”, and pointing out a couple dozen spelling and capitalization errors (these were incredibly difficult for fourth graders to spot, even when I told them in which word to look), the rest of the exclamation marks went away. Most of the class had a runnable program.

One 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.

* * *

Within hours of the class ending, I received an email from a mother saying that her kid was struggling to understand how everything worked. Perfect, was my first thought, 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.

* * *

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.

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 was just 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 something went wrong, not just in their code but in their life, 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.”

* * *

In week four, we created Tic Tac Toe, starting the project from scratch. Unexpected students got better. Others started to give up. Kids got busy and started to come 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:

On the other hand...

These were, I suppose, tradeoffs 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!