Philip Guo is best known these days for The Ph.D. Grind, but I first met him through his Online Python Tutor. He helped teach a bootcamp for librarians last August, and recently wrote a blog post about the two cultures of computing that he encountered there. On one side he sees users who treat software as a tool for getting things done; on the other, he sees programmers who hold conversations with their software. The former use stand-alone GUIs backed by binary file formats (like Word and Excel), while the latter use command-line interfaces and text (like the shell, LaTeX, and Python). He writes:
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:
|Typing "widgets" into Spotlight||vs.||
|Rich text editing in Word||vs.||ASCII editors that don't even do italics|
|"Create chart" in Excel||vs.||writing 15 lines of matplotlib after installing the right libraries|
|Copy-rename-email||vs.||"hours of jargon-filled confusion and typo-laden frustration" to learn Git|
|"Track changes" in Word||vs.||typing backslash-gibberish in LaTeX so that you can use version control|
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 .
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  and teach what's most rewarding first . 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 . 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 .
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 . 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.
xargsseems 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").
You can review our commenting policy here.