Blogging the first day of ICER 2010

I was only able to attend the first day of the International Computing Education Research (ICER) workshop, but it was still worth the long trip to Aarhus, Denmark. Aarhus University is very pretty, and the town is interesting and fun. We had less than 40 attendees, so it was a great setting for great discussion.

The chair, Michael Caspersen, came up with a new structure for sessions this year. Each 90 minute session had two papers. Each paper was presented for 25 minutes, with a few minutes after for clarifying questions. Then, attendees were asked to talk with people sitting near them for 3-4 minutes to develop questions for the two speakers. Yeah, I know that I just said that I hated “active learning” in a conference lecture, but this really worked. It didn’t take anytime from any speaker (it’s hard to talk beyond 25 minutes about a maximum 12 page paper), and the people seated around me (because of the small size of the workshop) were people I knew and whose opinions I valued. Having 20 minutes of discussion, with both speakers, after having “primed the pump” with local discussions was great.

The first session had two papers on creating taxonomies for use in reviewing and organizing the papers presented over the last six years of ICER, to get a sense of what has and hasn’t been explored. The taxonomies were insightful and interesting, but they didn’t really get tested just looking at ICER papers. ICER means a lot to me, having been involved in setting up, but it’s still a small, relatively new conference. There have only been 72 papers presented so-far. There is a lot more in computing education, which would be useful to review and categorize. The papers and discussion led me to think of a couple kinds of categorization efforts I’d like to see:

• It would be interesting to take some taxonomy from psychology or education or sociology, and see what parts of it have mapped or might map into computing education.
• I’d like to see a review of computing education research that’s not showing up in ICER or related forums, e.g., maybe in Journal of Engineering Education or FIE?
• Finally, there’s a lot of work in computing education research that appeared and then disappeared from the ICER perspective, like cognitive tutors for teaching programming or worked examples for recursion. It would be fascinating to do a graph analysis of what papers referenced what other papers, to look for gems that generated a cluster of interest but have not been fully developed.

The next session was where I presented Brian Dorn’s work, interviewing graphics designers to figure out what they want to learn about CS and why they don’t take classes to learn it. Leigh Ann Sudol and Ciera Jaspan had a really surprising and intriguing paper about the misconceptions that undergraduates have about software engineering. For example, they found that the number of misconceptions that sophomores have is less than frosh, and juniors less than sophomores — but then seniors jump back up with greater variance. They found that sometimes have more internships or working in web applications led to students more confusion and doubt about software engineering.

Moti Ben-Ari gave the keynote talk, Non-Myths About Programming. He had seven statements that people today talk about as being “myths,” but he says are quite true.

• #1: Programming is boring. But so is everything else, says Moti. Even the specialist surgeon gets bored doing the exact same thing for the 5000th time. He suggests that television may be influencing our students’ belief that everything should be exciting and all problems can be solved in 45 minutes.
• #2: You have to sit in front of a computer all day. So does everybody, he says. Some jobs, like travel agents, sit in front of computers even more than programmers do.
• #3. You have to work long hours. Moti asks, “What professional job today does not involve long hours?”
• #4. Programming is asocial. Moti argued, “No one ‘chats’ with his/her ‘clients.'” He says that some students may feel that, “I prefer helping people directly, say as a social worker, than creating computerized ‘things’ people need.” Programmers help people, and talk with their clients as much as doctors do.
• #5. Programming is for those who think logically. Totally true. Most jobs also involve thinking logically, but if you can’t, don’t go into computing.
• #6. Software is being outsourced. It is, but not the interesting stuff. He says people do things in software that they don’t quite know how to do yet. If they knew, they’d manufacture hardware to do it. If you don’t know how to do something, you don’t send it away to get it done. He had a great story about Margaret Hamilton who led the development of the Apollo software systems. He says that NASA could never have outsourced the development of the Apollo software.
• #7. Programming is a well-paid profession. So what’s so bad about that?
• He then said that there’s a new myth being propagated that he dislikes, that CS is NOT primarily about programming. He says it is.

Moti did say during his talk that he’s against contextualized computing education (fairly pointedly to me). He says that it’s okay for a short while to gain motivation, but decontextualized knowledge is better, more transferable, and more creative. He says that we ought to teach kids to have more fortitude to get through hard things. We talked about this point after his talk, and I told him that I agree about the value of decontextualized knowledge. I don’t think you have to start (and maybe for many student, can’t start) decontextualized, particularly for those students who don’t want to become CS majors.  Moti is willing to start contextualized (e.g., with Scratch), but wants to students to shift into decontextualized fairly soon.  Maybe we just disagree on the definition of “soon.”

I chaired a session with two papers on teamwork. Dave Largent presented a paper (by him and Chris Luer) showing that the Tuckman’s “Forming, Storming, Norming, and Performing” model of team behavior matches what happens with student teams, too. Sue Fitzgerald presented a paper where she and her colleagues (Laurie Murphy, Brian Hanks, and Renee McCauley) used transactive discourse analysis to identify the kinds of statements that pairs made when debugging which most often led to success. The discussion got into when pair programming isn’t a good thing and whether or not it would help student teams to know what to expect — would they be able to use the knowledge fruitfully?

The banquet that night was amazing. The folks at Aarhus really know how to throw a party! It was great fun just exploring the center of Aarhus, staying across the street from their huge theater. I wish I could’ve stayed for the second day — I’m typing this now while on the flight home, to catch up with my kids in their first week of school.