Here’s What I’ve Learned So Far
Heather Payne is smart, hard-working, and not afraid to dive into things she doesn’t know. Starting from nothing more than a tweet six months ago, she and her colleagues have built an organization in Toronto called Ladies Learning Code that runs workshops to teach women basic programming skills. A couple of weeks ago, she set herself a goal: she wanted to build a simple little dynamic web site. Yesterday, she blogged this under the heading, “Here’s What I’ve Learned About Programming So Far“:
Respectfully, I disagree. Programming itself isn’t intrinsically hard; what’s hard is all the crap we make people like Heather wade through to get to the programming. I’ve been programming professionally for 29 years, and I’m still baffled, frustrated, and angered by things going wrong when I’m trying to set up a new workspace. Install this—oh, but wait, it depends on that, and the package manager I’m using doesn’t install the right version of that by default, but the error message telling me that only makes sense to five people on the entire planet, so off I go to a Q&A site where someone inevitably says, “It’s easy—you just…” Saints and small mercies, I hate that word—hate it and dread it. “Just” means “I want to make your problem sound trivial.” “Just” means “I refuse to acknowledge that we’ve buried your actual problem in so much accidental complexity that you’ll have to dig for hours to get to it.” Whether it’s a bureaucrat saying, “Why don’t you just fill in this 25-page form,” or a programmer saying, “Why don’t you just switch languages,” its real meaning is, “Your time means nothing to me.”
I’ve been teaching programming off and on for 24 years, and what I’ve learned reflects something psychologists discovered back in the 1970s. Suppose I give you a choice: you can either wait for the bus for 10 minutes every day, or you can wait 1 minute four days a week, and 20 minutes the fifth day, except you won’t know in advance which day each week is going to be the long wait. If you choose the second option, you’ll wait half as long on average, but almost everyone prefers the first because it’s more predictable. Similarly, if you can choose between a task that will reliably take an hour, or one that will usually take five minutes, but will occasionally take a full day, you’ll choose the former—you pretty much have to if you want to be able to plan anything else.
And that is where we, as programmers, have failed. When Heather and people like her sit down to start programming, they have no way of knowing whether a seemingly-simple task is going to take 5 minutes or 5 hours, because we, the professionals, don’t know either. Oh, we’re probably better at guessing, but we don’t know. And yes, other things aren’t really predictable either—painting a wall can take half a day instead of 30 minutes if you accidentally knock the can over and have to clean it up—but programming has much bigger error bars than anything else I do.
So here’s what I’ve learned so far from almost thirty years of programming and teaching. If we really want it to be something that most people can do, the way most people can do their taxes or change the oil in their car, then we have to make it more predictable. We have to stop excusing ourselves with the J-word; we have to stop saying, “Oh, but of course the debugger won’t work if you’re running a Tkinter application, because the Tk app grabs the event loop,” which is about as fair as saying, “Oh, but of course it rains when you wear red on Tuesdays” (the “…you idiot” at the end of that sentence may be silent, but it’s always there). We don’t need to simplify programming itself: we need to throw away all the crap that’s piled up on top of it. A “simplified for novices” layer on top of the crap won’t work: all abstractions leak, and the interface between the simplification layer and what’s underneath it will be a breeding ground for more incomprehensible bugs.
If we have made programming difficult for someone like Heather, then we should be ashamed of how poorly we have done our jobs. I don’t know what the solution is, or if we can get from here to there, but as far as I’m concerned, it’s the biggest challenge computer literacy projects of all kinds face.
I agree here Greg, programming is not hard but the tools we use to teach make it hard. I too came to that conclusion about 5 years ago and am still trying to create an environment that removes all the crud so students can just learn to program (and other tasks) without the distractions. Bravo.
It shouldn’t be surprising that languages whose design is optimized for experienced programmers are difficult for other people to learn, because of the tradeoff decisions that were inevitably made. Some educators start off with beginner languages that are designed specifically for novices (languages with proper implementations, not layers on top of something else) — that’s how BASIC started (B=Beginner’s) — and that seems like a pretty good idea to me.
One of our failures has been that we haven’t recognized that programming can be hard even for smart people. Story 1: When I was marking CS 250 assignments at the University of Waterloo (CS 250 was the low-level programming course, with the language being assembler for a machine designed specifically for teaching) I was often faced with a program that was clearly written in a logical fashion but based on a flawed central assumption of some sort. Fortunately I was often able to figure out what that incorrect assumption was and let the student know; without that the student might never have been able to write a working low-level program. Story 2: I once had to fire a programmer who was brilliant at math (competition level) but couldn’t code his way out of a paper bag: everything he wrote had to be rewritten by the other programmers. I wondered how someone like this had been hired in the first place; it turned out that he had a CS degree from Waterloo. Which obviously reflects badly on the university, and devalues my own CS degree from there, but the point I’m making here is that this was one very smart cookie who still hadn’t been able to learn how to program decently.
So I question the effectiveness of including “real programming” in computer literacy projects. Heather Payne calls LLC “a collective of women working to empower everyone to feel comfortable learning basic, beginner-friendly programming and technical skills”. I think she’s right to include “basic, beginner-friendly” — and languages like JavaScript do not qualify.
“…languages whose design is optimized for experienced programmers…” implies that (a) we know how to measure how productive languages are in the hands of various people and (b) these measurements have actually been done. As far as I know, efforts to do this were largely abandoned after a promising start in the late 1970s and early 1980s. I strongly suspect that despite all the noise advocates of various languages make about them being “natural”, “intuitive”, or “powerful”, we’d find that most of today’s “beginner” languages are not significantly easier for novices to understand than ones with more complex syntax or semantics. Anyone want to fund the study?
Greg,
I spend most of my time hand holding and explaining to students – who arguably have learned computer languages – how to wade through the swamp of installation and configuration. I am not optimistic that this will change. It gets worse over time. Students used to know HTML. Now they know Facebook. I have Comp Bio students, in CS courses for 3 years, and I still have to teach them how to install a Linux distro, what a package manager is, (how to free the lock on the package manager). Then how to install MySQL, how to configure an initial database, how to install ODBC drivers and configure them. Then how to modify a Perl script that downloads and populates a Bioinformatics SQL database. Then how to load the R package which compiles C code and has even more dependencies. Then finally I can show them what I really want them to learn, which is to use R to query, extract and summarize data. Mostly I am teaching plumbing, not data analysis. If I canned it all for them in advance they would be helpless in a real job setting or grad school. So I have to spend 6 hours of class time teaching what CS won’t teach. Sigh.
“… and languages like JavaScript do not qualify.”
If you’re running Chrome, you can press CTRL-SHIFT-J, and you have a Javascript interpreter working. JavaScript may be a quirky language, but it doesn’t suffer from the same problems Greg is talking about.
I’m not sure I agree about its problems: its inconsistencies and outright design flaws trip up even experienced programmers, and as soon as you want to use it outside the browser, you have the same “which version is this? why won’t it install beside XYZ?” issues as other systems. That said, I haven’t used things like node.js in anger (yet), so I’m just going by what I’ve heard other people gripe about…
Regarding measuring the productivity of languages, there is some work you might find interesting surrounding the Quorum language. In particular, this paper compares the productivity of novices learning Quorum, Perl, or a so-called placebo language. I haven’t explored whether or not this group’s research exists in a vacuum, but at least it is something.
Thanks for the pointer, Jack — I’m co-editor of a blog called “Never Work in Theory” that featured this paper, and I’m glad it’s getting attention.
As of jQuery and other “standard” libraries, cross-browser JS nightmares are mostly a thing of the past. The only outside-the-browser environment worth considering is now node.js, which at least narrows the field, but really, who cares about outside the browser when the goal is just to get people going?
Cross-browser issues may have been hidden, but Javascript’s own design flaws remain: if a novice forgets a ‘var’ in a function, things can get pretty ugly (incomprehensible) pretty quickly.
You have singlehandedly guilted me out of a word from my email vocabulary. Thanks, Greg!