How not to teach hacking

Audrey Watters talks about the gap between her desire to learn coding and xMOOCs‘ pitiful exploitation of code-learning desires in My Code Year. Over the year, she has described her various efforts at coding-related MOOCs and the ways in which the various courses have failed to meet her needs as a working adult with her level of experience at computers. I gather that her experience and skill level is much like those of millions of others: thousands of hours using computers, including various technologies (Watters writes several blogs, podcasts, and is active in social media), but not comfortable enough with hacking to be where she’d like to be:

I want to be able to support my sites — everything from the DNS to the database. I want to control my digital identity. I want access to my data. I want to be able to ask questions that data and against any open data in my profession (for me, that’s education). I want to be able to solve my own digital problems — and not just, “please cycle the modem” sorts of bullshit. I want to be able to hack my world.

That’s an eminently reasonable goal, and the failure of xMOOCs to meet that goal is a design feature.

Why do I call the failure a design feature?1 It comes from the basic fact that few faculty members at an elite institution would create a course on messing around enough with various systems to learn how to hack. No: the publicity around MOOCs emphasizes the choice of a discrete chunk of stuff to learn, with maybe a specific project as the target for the end of a tech-oriented course. That’s scalable with current technology, as long as you know you will be missing the needs of the vast majority of starting participants. (More on that below.)

It strikes me that the design of a hacking experience requires the coding equivalent of Mills Kelly’s “disruptive pedagogy” concept, or an entire course focused on tweaking and breaking (and putting back together). You can create a sandbox for such playing online, but that’s limited to the types of systems that are congenial to virtual sandboxes. And I think participants would tire of such sandbox exercises in … oh … about three days.

Instead, a tweaking-and-breaking course on hacking requires real systems, both hardware and software. To serve the purpose of the course, there have to be real consequences for the choices of participants, not just a gentle “oops, try again” as a screen message. Yes, a sandbox approach can be useful at the start, but the real-life needs Watters mentions above are unstructured, unpredictable, and highly stressful. So an effective course on hacking has to create some of those conditions, progressively, where the scaffolding and support (you know, teaching?) is available for those unpredictable glitches that not only are inevitable in any tech-related course but is desirable from the standpoint of my imaginary ideal course on hacking.

In lab courses, we call this support “the lab instructor,” someone who students can call over when equipment doesn’t appear to work right. A great lab instructor is best at judging where support should be specific technical advice and where support should be encouragement and “you can get this if you work a bit harder.” Great lab instructors do not exist in Coursera, EdX, or any other xMOOC platform. As a result, my guess is that an xMOOC participant is most likely to conclude the course successfully if she or he already has significant hacking experience… that is, enough experience and skills that a participant can get around the inevitable glitches with a little bit of independent effort.

I’m involved in one of those xMOOCs right now. But you wouldn’t probably call it that: I’m just running through a pretty good textbook on learning Bayesian statistics. This is a well-above-average text for a technical course, because it wasn’t until Exercise 7.5 that I hit something that required knowledge available nowhere but in the answer key. Usually, courses that require software packages have an early installation/learning-the-environment hurdle, where a student needs to learn how to navigate in a largely-unfamiliar environment (which often uses conventions different from a PC or Mac’s operating system, so file interfaces are as awkward as 12-year-olds kissing through braces). And then in the first problem set, there are almost inevitably problems that are poorly-constructed or that omit critical information. In a course with a live lab instructor, those glitches are taken care of by individualized (or small-group) hand-holding. Since I’m working through this on my own, I am delighted that the recommended software package is great, that I am not wasting my time inventing new typos while I code the exercises, and that I have enough counts-for-hacking experience in stats software to get me independently through predictable levels of glitchiness (and that solutions to the exercises are available for Exercise 7.5 and any other seemingly-impossible problems).

But Watters’ goals are to get to that point and a few long stretches beyond in multiple areas. xMOOCs are design failures for those goals, unless someone can figure out how to pay the virtual lab instructors to answer calls 24/7 about a mix of software and hardware problems. Until that happens, xMOOCs essentially have the XKCD Tech Support Cheat Sheet available for course participants.

Incidentally, I’m not worried about Watters’ learning to code. If you haven’t read her blog entry, go there now and read it to the end.


  1. This discussion is in addition to Watters’ discussion of goals and motivation. []

One response to “How not to teach hacking”

  1. Glen S. McGhee

    Of course, no one will share secrets like the ones she wants — there is no pay off in doing so. What we end up with is her blog instead.

    What she really wants — but doesn’t know enough to give it a name — is apprenticeship and mentoring. But this is a social institution that died out 150 yrs ago, for the same reason just given.