The latest interview in my research for Mozilla...

Mark Guzdial is a computer science education professor at Georgia Tech. That joint disciplinary background -- CS and Education -- is particularly important and interesting, I think, in terms of both the what CS education should entail and the how. Guzdial created the Media Computation approach to teaching introductory computing. As such, many of the students in Guzdial's CS classes are non-CS majors. Some of Guzdial's recent work also involves working with high school CS teachers, many of whom come from a business rather than a CS background. Guzdial's blog is the Computing Education Blog

Research: Improving non-programmers' basic understanding of CS: Guzdial told me about the research conducted by one of his grad students, Brian Dorn. Dorn studied the CS understanding of graphic designers who'd taught themselves to code (primarily to script Photoshop). These people didn't label themselves as programmers, they were often inefficient at programming, and often their code was "atrocious." But they were able to "hack" enough to save time with their design work, primarily by using a lot of code repositories.

In the research lab, however, it was clear that these people's understanding was severely limited (e.g. searching for help with Javascript and looking for an answer on a Java website). Dorn was interested in the question of how he could improve their basic understanding of CS. He created 2 code repositories: one with a bunch of code and one that was a "case library" -- a code repository that additionally gave stories that explained how the code was written, in which he explicitly used CS language (e.g. "this is a boolean." "this is exception handling.")

The repositories were given to 2 groups. Both were able to program successfully. They liked the tools the same. But those who received the case library were able to pass a test afterwards about CS concepts.

Problem with creating a new tool: The problem of self-efficacy -- if you give people a new tool, they feel as though you're telling them they are not able to learn "the real thing." Their self-efficicy is then reduced as it's not as motivating to learn something that's a "toy." Not everyone is self-confident enough to not have this problem. Common fallacy that some people just aren't "cut out for it." So Guzdial says that's the danger of creating yet another tool.

Situated learning: In most naturalistic learning situations (e.g. midwife apprenticeships), there's a notion of "legitimate peripheral participation." (e.g. handling towels during a birth) In other words, when you're learning, you want to do something real, but on the periphery. What every student wants to do is to move to the center of the community of practice. "If you give somebody a new tool, what's the community of practice for that tool. Who uses that tool?" And do people want to be an expert in that tool? Or do they want help getting into the community of practice?

What do students want?: When Guzdial was going to teach the second course in his Media Computation class, he surveyed students to see what programming language they wanted to learn. "Pick some weird language," said some students. "No, said others." They wanted Java, not Python. According to the business majors, they wanted to learn Java because potential employers would know what Java was, whereas they wouldn't know about Python or other programming languages. Survey (potential) students and see what they want. What are their learning goals? The danger (and wow, am I guilty of this!) is just to talk to teachers. "Teachers talk to the most interesting students in the class, or the ones that come and bother them the most."

Short term versus long term goals: The short term is figure out what people want, teach that on the way to creating more Web builders. The longer term -- such as Bret Victor's video -- is about rethinking programming. That's exciting, or exciting to the technical community. But it's not what people want now. So you can create a bunch of tools for now. Or you can create tools for building a future community.

The Feynman mystique: How are some of these new CS education efforts really just about teaching programming to people who already program? Is this what we're seeing in the Stanford AI and Udacity classes, for example, in which the vast majority of students actually drop out, in which a lot of those who enroll are AI professors and/or software engineers? Guzdial told the anecdote about Richard Feynman's undergraduate lectures that, by the end, were only attended by grad students and faculty as the undergraduates could not possibly keep up. People praise Feynman's teaching on physics, but for the CalTech undergrads "it didn't actually work." It was really great, however, for experts to flesh out their understanding. But it doesn't help people who need to develop an understanding from scratch.

Hypercard: Alan Kay claims that HyperTalk is still today the most powerful popular end-user language ever. One-third of folks with a Mac built something with Hypertalk -- if that's true, that's millions of people and that outnumbers other programming languages in use today. So what's interesting about HyperCard then, says Guzdial is both its success and its failure. HyperTalk was designed to be easy to learn. "This answer was definitely not Java or Python or Scala." Interestingly, the research from the Eighties said that the easy-to-learn ones tended to be wordy-languages. HyperTalk didn't continue, in part because Apple didn't support it. But also because "expert programmers" hated it, as they tend to like terse programming languages. "The wrong community of practice killed the tool." Everyday people didn't want to use something that the experts said was terrible. But HyperTalk wasn't made for experts. Yet, everyday folks didn't have a strong enough community to support one another either.