Motivating Students

Because of a session on remaking the Image of Computing, there were a bunch of famous people at the NCWIT meeting this week. Perhaps the one of most interest to me was Kate Starbird. Not as much because she is a retired WNBA player (though that's pretty cool!) but because she's really smart, really nice, and really articulate. She pointed out that she was the only person there to talk marketing who also had a background in CS.

Remind me to tell you about the argument she and J Strother Moore got into.

But first, I want to consider the question of inspiring students to learn about computing at a deep level. When I Googled Kate, one of thetop links is to a great blog post she wrote. Here's an excerpt:

Like many of my generation, I grew up on a computer with little or no content, and if I wanted it to play, I had to be creative. I had to make it do what I wanted it to do. I went on to study computer science in college and graduated with a BS from Stanford in 1997.

My youngest brother Michael followed me there, and majored in CS as well. He works for Microsoft now. By the time Michael was nine our family had a game console for our TV and fantasy adventure games with elegant graphics on our Apple IIgs. He grew up playing Nintendo and Bard's Tale. He had an email account before he was out of high school, and knew how to browse the Internet long before I did.

Unlike me, though, Michael didn't write a single line of code until college. Michael was an extremely creative kid, but he didn't bother spending that energy creating loops, routines, and functions.

This is in line with a thought I had last summer about learning curves vs. quality of output.

When we were kids, computers were pretty limited in what they could do. You could write a program in BASIC that was almost as good as the programs you could get on floppy at those game swap events on Saturdays. You could buy BYTE magazine and laboriously type in the programs, seeing exactly how the program was put together. It was reasonably straightforward to create programs that were engaging, that your friends would say, "oh cool!" (or the 1982 equivalent) if you told them or showed them.

The world has changed a lot. A kid in the basement couldn't have written World of Warcraft or the Sims. In some ways the tools we have make it easier than ever to create interesting content - Dreamweaver making HTML and PHP at the click of a button, drag-and-drop programming in Flash or Alice, image manipulation with iPhoto or Photoshop - those were all inconceivable back then.

But the increased complexity under the hood - the higher computational power in home computers, the embedded systems throughout our lives - have also abstracted away our ability to tinker. Imagine taking apart your iPod to see how it works. Similarly, kids are so used to interacting with fun! neat! systems, that the introductory programs they're cognitively ready for aren't impressive enough. Hello World just doesn't cut it in our in-your-face media-rich world.

My students struggle with some of the ideas of CS. That a variable contains a value is a new idea for them. They're smart, capable, and they figure it out, but there are developmental issues - their brains aren't ready for all the deep ideas. Yet they will get turned off if it seems like too much work for too little payoff, if they can't make things that make their friends say, "oh cool!" (or the 2008 equivalent).

Teaching Programming

We started the programming unit yesterday.

This year I'm switching from Perl to Python. I'm also hugely overhauling my teaching style. I was convinced by Vern Ceder (and various other sources, I'm sure) to get to graphics as fast as possible and skip the endless pedantic slog between here and there. In nearly all of the books I have used as resources, graphics are late, late, late. I decided to take a page out of the media computation book (not literally, but mostly only because I don't have a copy), introduce graphics as fast as I can and do lots of Just In Time teaching to backfill what students need as they care about it.

I want to mention my incredible gratitude and luck at the support I've received. Vern's presentation at NECC 2007 was transformative in my thinking about this unit. Getting to participate in the Chapman University workshop about teaching Python gave me the basics of the language. And most amazing, I have been meeting with Guido van Rossum regularly this fall and winter. He has reviewed my code, explained concepts without demeaning my lack of knowledge, and regularly reminded me what beginning programmers are like when I waver about presenting the material in this unusual, out-of-order way. He might be the nicest super-geek I've ever met, though Tom Zeller is right up there.

Day one went great! I started the students out in IDLE in interactive mode. We walked through print statements with strings and then numbers. It was great - the kids let right to the places I wanted to go, like learning about a syntax error when

2x2

didn't work the way they thought it should and testing what happens when you put math into quotes. I introduced variables super-quickly - in the past, variables would have taken an entire period, this time it was almost an aside, as a way to do math. Similarly, I introduced for loops and the range() function in about 3 minutes because I was up against the end of the period. The kids followed pretty well. I stopped to check the comprehension level several times and while it was slightly overwhelming, they were fitting it together pretty well. One thing that went very well was that I'd grabbed a few photocopies of their math textbook so I could show them how to use Python to program some of the problems they would face later that day in class. The whole concept of working collaboratively with other teachers is the subject of another post, but I was very happy at drawing the connection.

There were a bunch of things that went really well. It was very interactive, the kids were engaged, and they were typing right along with me. I think they really got that you can (and should) create hypotheses and test them right away. "What if you do blah?" "Let's try it" "Oh, cool!" They had terrific ideas and were able to figure things out really fast.

There were a few things that were, um, sub-optimal. For one, I had planned WAY more than I could reasonably teach in one period and didn't cut myself off fast enough - I was too excited about the connection to math. I would have liked to have given the students a small homework assignment to write a program and didn't have time to do so. I'm okay with it since not having homework makes the students happy and I'd like them to think programming is fun. Yeah, not optimal, but I'm looking for the silver lining.

Second, the Just In Time teaching requires the teacher to be flexible and able to quickly analyze situations to figure out what is going on and what is worth covering. Some of the time that worked well - on the fly I decided not to cover modulus and the sqrt() function in the math module. Some of the time it didn't work well. Their math problem was to determine five values of x that would make 2x-6>=3 true. I showed them how to do it but then was preparing to segue them out of interactive mode and into script mode since it had to happen 5 times. (This was also where loops came in, even though it meant skipping conditionals!) In one class, a student suggested just programming y=2*x-6>=3 and then iteratively changing x and re-evaluating y. Which, of course, didn't work right, but on my feet I couldn't remember that it was because y had been set by what the formula evaluated to in that moment. Duh. It wasn't horrible, but I should have known better.

Tomorrow I will show them two longer programs - one that is a "guess a number" game (binary search!) and one that generates Shakespearean insults. Then they'll be on their own to write a little program. So exciting!