Lost in Space

This post originally appeared on the Software Carpentry website.

You probably haven't seen the 1998 movie Lost in Space, or if you have, you've suppressed the memory—it was awful. But I do know one guy who enjoyed it. His name was Joe, and he had worked on the software used to create its special effects. Ten minutes into the film he took out his Walkman (a primitive form of iPod), put on his headphones, and spent the next two hours head-bobbing to a mix of Bob Marley and Smashing Pumpkins.

Joe enjoyed the movie because he was looking for something different in it than the rest of us. Luckily for him, the story and dialog were irrelevant; what he cared about was edge glitches in spheroid lighting effects, which made the after-movie discussion with the rest of us rather surreal.

Something similar happens pretty regularly on our 'discuss' list. This week, for example, Ben Marwick's message about Docker containers generated a thread with a couple of dozen replies (and counting). Some of the discussion is about the mechanics of deploying Docker, resizing windows, and so on; other parts are about what happens in the classroom when you do this and what novices find easy or hard.

It feels in places like two conversations have been interleaved—like some people are looking at the effects and others are thinking about character development. Given our mission, we need to have both, but two things make this complicated.

The first issue is the disparity in the social license to comment between education and technology. People generally accept that non-experts are entitled to have and express opinions on some topics, such as foreign policy, how usable different programming languages are, and what the local sports team should have done in last night's game. In other areas, though, such as virtualization or heart surgery, there's an implicit social agreement that only the cognoscenti should speak out.

Teaching pretty clearly falls into the first category: people who have never encountered the literature on educational psychology still feel they have something to offer based on personal experience. And they're right: when analyzed systematically, their (qualitative) anecdotes can provide insights every bit as much as statistics. The key word in that sentence is "systematically", though, and this is where I most keenly feel the gap between what Software Carpentry is and what it could be.

Second, most of us (myself included) know more about technology than education, and therefore tend to gravitate toward the former. But as one person on the list said to me privately over the summer, that means that many of our discussions of teaching wind up going down a technical rabbit hole, leaving the less technically inclined behind.

The Japanese math teachers that Green described in Building a Better Teacher have only half the problem we do: they "only" need to figure out how to teach math, not how it works. The trick for us is to find a way to mix discussion of both sides of that coin in a way that keeps everyone engaged.

After the movie was (finally, thankfully) over, we all went across the street for pizza. The conversation that followed moved back and forth between "how do you think they did that smoke effect?" to "wow, even when Gary Oldman phones in a performance, he's pretty creepy" because we were graphics programmers as well as movie fans and didn't see any reason not to think both ways at once. I think that's a pretty good model for Software Carpentry; I think that asking "what's the tech?" when someone says "here's the teaching" and "what's the teaching?" when someone says "here's the tech" helps us all learn more about both.

Coincidentally, as I was wrapping up this article I received a link to a paper by Zagalsky et al called "The Emergence of GitHub as a Collaborative Platform for Education" that quotes some earlier posts from this blog. The discussion of what people are doing, both technically and pedagogically, is another good example of the kind of interleaved discussion that we have been having about Docker.