On Crossing Australia (or, Further Thoughts on What to Teach Researchers about the Web)

This post originally appeared on the Software Carpentry website.

A while back, I blogged about Bret Victor's "Inventing on Principle" talk at CUSEC'12, which is an inspiring vision of what programming could be. Ned Gulley's thoughts on it are more nuanced (and more interesting):

Victor's real power is his ability to rapidly create and deploy these tools. In a twinkling he can size up a task that is worth studying, put a box around it and spin a tool. He does this so effortlessly, with such mesmerizing legerdemain, that we lose sight of this meta-skill. What Victor was really doing in his talk was illustrating the power of tool spinning, the rapid creation of customized, context-sensitive, insight-generating tools...

Don't use the thing Bret made. Do the thing that Bret does.

That last sentences crystallizes what I've been groping toward as I think about what we should teach researchers about the web. I want to give them the power to do whatever they want to, as effortlessly as possible, because (a) I can't anticipate what they'll actually need, and (b) what they need is changing all the time. The problem is that there's a wide gulf between simple things that are easy to do (e.g., tweaking CSS) and/or playing in a sandbox that we create (e.g., pointing an in-browser visualization tool at their own data) and being able to throw together something that we didn't anticipate (e.g., build even a small web app using jQuery and Django, or any comparable set of tools). It's sort of like Australia: lush and green in Sydney and Perth, but there's a loooooong trek through an inhospitable desert to get from hither to yon. By comparison, desktop programming (e.g., the media-based curriculum that Mark Guzdial and others developed) is a lot more like hiking from Halifax to Toronto: there are certainly difficult patches, but at no point do you find yourself stuck in the middle of nowhere [1]. That desert in web programming—the long, unrewarding gulf between the simple and the powerful—is what makes this hard.

"But wait," I hear you say, "What is this 'gulf' you speak of? It only takes a few minutes to show someone how to write a simple CGI script, or to tweak some PHP to modify a WordPress plugin." Well, yes, but that's like saying that it only takes a few minutes to show someone how to start a car and get it out on the road. It's what we have to teach people so that they can survive what happens next that takes time. As I said in my earlier post, all we can teach people about server-side programming in a few hours is how to create security holes. You or I would know to scrub input before using it in a database query; we could tell novices to do that, but they wouldn't have the context to understand what that really meant, or how to do it properly. The best we could hope for is that they'd memorize a few rules, some of which some of them would then mis-apply.

I was actually a bit surprised that Mark Guzdial was surprised by me including security in my list. If I give a teenager the keys to my car [2] and let him take it out on the road without suitable instruction, I think I'm morally liable for the resulting catastrophe. Similarly, as long as we were only teaching people how to build things that ran in the safety and privacy of their own machines, the worst they could do was delete their home directory (been there, done that—twice). But the web has changed this, just as it's changed everything else.

So how do we close this gap? Partly, I think, by making things easier to drive: as Audrey Watters reminded us in summing up the research she did for Mozilla, tools like HyperCard put most of the power of "real" tools in the hands of end-user programmers: educators, graphic artists, businesspeople, and everyone else who doesn't think of themselves as a software developer but wants to make something happen. Yahoo! Pipes, If This Then That, and things like them aren't nearly as powerful, yet, but I think they're more interesting than any number of "live coding in the browser" tools that still expect you to be typing Javascript into a text box.

Which brings me back to Mark Guzdial's post, and to his discussion of Juha Sorva's wonderful work on UUhistle (a program visualization tool):

One of the arguments that [Juha]'s making is that the ability to understand computing in a transferable way requires the development of a mental model—an executable understanding of how the pieces of a program fit together in order to achieve some function. For example, you can't debug without a mental model of how the program works... Juha's dissertation is making the argument...that you can't develop a mental model of computing without learning to program.

To which I would add, "And most people won't learn how to program unless each step lets them do something they care about, safely, that they couldn't do before."

[1] OK, it's not the smoothest analogy I've ever come up with, but you get the picture.

[2] I don't actually drive (haven't in 20 years), but I've never let the facts get in the way of making a point :-)