Tools, Conversations, and Cultures

The 35 students all came from user culture, whereas the 6 instructors all came from programmer culture. Not only did the students need to learn new technical skills, but they also had to get accustomed to the ways of programmer culture. And some instructors—who had been living firmly in that culture for decades—had a hard time relating to the students, despite their most sincere efforts.

As a result, it was sometimes hard to motivate students to learn programming-related skills, since they felt like they could accomplish similar things with the tools that they already knew. And it's not just this one isolated event: when I've witnessed programmers teaching beginners in several other contexts, this same Two Cultures schism keeps cropping up again and again.

Philip then enumerates some examples that will be familiar to most Software Carpentry instructors:

Looking at this list, it actually is easier for users to do the things they're currently doing with the tools they're currently using. The conversational approach only pays off at scale, and even then only after investing a lot of time [1].

Okay, so as an experienced programmer, what can you do to help beginners learn?

I think the most important first step is to acknowledge that students are often coming from a vastly different culture than the one you inhabit, and that programmer culture just seems weird to them.

...

You need to gently introduce students to why these tools will eventually make them more productive in the long run, even though there is a steep learning curve at the outset. Start slow, be supportive along the way, and don't disparage the GUI-based tools that they are accustomed to using, no matter how limited you think those tools are...

In the short run he's right: given the tools we have, all we can do is keep Glass's Law in mind [2] and teach what's most rewarding first [3]. But Philip's "two cultures" aren't a reflection of some deep physical law. The split is an artifact of history, and there are lots of systems that deliver the best of both worlds. High-end computer animation tools like Houdini and Maya let people mix graphical interaction with textual scripting, and while hard-core programmers may sneer at Microsoft's Office suite, it's amazing what can be built by combining Excel's direct manipulation of data with scripting in Visual Basic.

Unfortunately, the key word in the preceding sentence is "sneer". When personal computers started offering human-friendly interfaces in the early 1980s, "real" programmers reacted with self-righteous envy [4]. That attitude became part of programming culture, and is one reason why programming has stagnated over the last 30 years [5,6]. We create rich interfaces for everyone else, but refuse to use them ourselves; we insist that everything must be text, then wonder why people who know that you can style text and draw pictures in documents won't believe us when we say we know better. It's cultural imperialsim, pure and simple: we're so convinced that we're right, and that they should join us, that we can't see how much we could learn from them.

Ten years ago, I confidently predicted that programmers were finally about to see the light:

We could still be writing and viewing programs a byte at a time in 2010... But do you really believe that will happen? Do you really believe that ours will be the only documents that aren't marked up, that can't contain heterogeneous content, that aren't processed by extensible frameworks?

For once in my life, I was an optimist. You still can't embed a diagram directly in the source code of your program—the closest you can get is something like an image in an IPython Notebook, but there's no semantic connection between the two, You certainly can't embed a spreadsheet in a Python source file, even when tabular dataflow would be the most natural way to express a computation, and most of us are still piping lines of text from tool to tool, even though PowerShell showed years ago that piping objects is both practical and more powerful [7].

I still believe we'll fix this eventually. Some day, someone will build a system that separates models from views so that people can freely combine an ever-growing mix of notations and formats to inspect and control every aspect of their computer's operation [8]. That system will allow users to have conversations with their tools, and give programmers the moral license they seem to feel they need to join the 21st Century. Until it arrives, though, we should do more than gently explain to students that our antiquated tools will eventually make them more productive. We should apologize for not building something better, and promise to try harder.

Footnotes:

1. Many programmers forget the years of hard work it's taken them to achieve a state in which find piped to xargs seems natural. The result is what's called "expert blind spot", often signalled by over-use of the passive-dismissive adjective "just" (as in, "you just blar blarg blargle").
2. "Every new tool or practice initially reduces productivity."
3. Software Carpentry's introduction to the Unix shell for complete novices takes half a day to introduce 15 commands. Most of the time is actually spent explaining the shell's productivity features: tab completion, the pipe-and-filter model, saving recent history to a file to create a script, and looping over sets of files whose names match wildcard patterns. The goal is to show them as early as possible that the shell will let them do things they care about that are tedious or impossible with GUIs.
4. I certainly did.
5. The things we build would seem like science fiction to my 21-year-old self. The tools we use to build them would instantly be familiar.
6. Programming languages, too. For all the advances made in type theory and optimization, programs are still expressed primarily as sequences of ASCII-encoded tokens; it's one of the few areas in computing where we insist on using a model as a view, to the detriment of both. As far as I'm concerned, improving the usability of programming systems by creating and assessing richer views isn't just the most interesting topic in programming language research these days—it's the only one that matters.
7. Hell, most version control systems still can't diff and merge HTML in a meaningful way...
8. It will probably come first from a vendor that already controls an entire toolchain (think MathWorks and MATLAB).