Bits and Pieces

by James Somers, March 27, 2011

A few months ago, a friend and I were talking about Sporcle, a popular website with moderately educational fill-in-the-blank quizzes. Their most popular page, for example, asks you to name the fifty United States. And here’s one that asks you to name thirty-two characters from The West Wing. There are many thousands more.

My friend thought Sporcle would be much improved if you could compete with other people in real time to fill out the quizzes. That way you’d turn lonely exercises into lively races.

Thinking this “multiplayer Sporcle” was a superb idea, I set out that night to build it. And remarkably I had a version that worked within three or four days, a feat I chalk up almost entirely to the deep brobdinagian complex of other people’s work that supports every modern programmer.

As I’ve steadily hacked away at the project, taking nights and weekends here and there to push out a new feature, preen the code, style some pages, and so on, I’ve been mostly oblivious to the growing complexity of the whole thing—the mess of technologies now implicated in even the simplest user actions. Without paying it any mind, really, I’ve darted fluidly among dozens of languages and dialects and libraries, thinking so little of their differences as to be effectively writing the entire application, top to bottom, in a kind of computational mentalese.

What I mean is that as I tab around in my editor touching some jQuery, then some Ruby code, then HTML, and then tweak some Apache settings, and tune MySQL, and push some new EC2 instances, and rewrite DNS entries, and thin out my Rails controllers, and wrap ActiveRecord around a Redis model, and rejigger some Capistrano recipes, and rethink my Passenger config, and on and on, the whole thing feels rather frictionless—I zip through each modal border-crossing like a well-heeled diplomat. I just slip from one file to the next, thinking mostly about what my application does, assembling the different pieces like so many LEGO bricks.

I hadn’t thought about how extraordinary this was until I took on a small handful of students (thanks, Tutorspree!), some of whom have never programmed before, and tried to look at my code the way they do. It’s been a fascinating exercise.

* * *

I have long known that teaching exposes what you don’t know. As you hazard an explanation or answer an unanticipated question, the cruft dissolves, leaving only what you understand well enough to describe in crisp, detailed English. Often it’s not much. I can’t tell you how many times I’ve begun to “explain” something only to stumble when my vague gist proves too shallow—too slippery—to render concretely.

What’s new for me, though, with these little compu-tutoring sessions, is seeing how much I do know. It turns out that after five years of programming in stints variously sporadic and immersive my brain has been colonized by fertile strains of cognitive tropes, skills, ideas, incantations, metaphors, and analogies that I never knew were there. Silent invaders.

It’s strange because I spend most of my time at the computer feeling like I’m faking it, pretending I know what the hell I’m doing but looking everything up along the way, frantically assembling the very ladder I’m climbing.

As it happens I’m a lot higher than I thought. It first hit me when I opened an old Rails project, hoping to walk through the high-level basics with a student looking to get into Web programming. Literally every file I fired up and every line I pointed to was for her a wonderful mystery. She didn’t know the difference between HTML, CSS, and Javascript. She wondered what Gmail was made of. She asked me what UTF-8 and the W3 were, and why they showed up at the top of most web pages (I got her in the habit of hitting “view source”), and what a DTD file is and who makes them, and what sorts of tags there were, and where all the names come from.

She wanted to know why the words on this tab had all those curly braces when the words on that tab didn’t. She asked what all the colors meant. She wanted to know why there were so many different languages that seemed to do the same things. She asked what you couldn’t do in a browser. She had heard of “servers” before, but not “clients,” and wanted me to walk her through what happens when you submit a form. She wondered what the Internet actually was.

When we started writing code together, she was deeply impressed by the idea of storing values in variables instead of copying and pasting them. She loved how programmers all use each other’s code, though she worried about running modules and libraries without knowing how they worked. She seemed intuitively drawn to the Unix philosophy.

We found that she could read some of my code right away—stuff like SQL queries and for loops—and some not at all (like functional Javascript, Rails models, and some Project Euler solutions).

She stopped me in the middle of a tangent: do people really write all that “view source” stuff by hand, in colorful notepads like the one you have open? What’s Dreamweaver do? Why do pages look different in different browsers? Where are the actual titles and articles and pictures coming from? Where are they stored? And what is a database, exactly? How is it different from an Excel spreadsheet?

With all these questions I started to get the feeling I sometimes get when I see new skiers bumble down the mountain: thank God I learned this stuff already. It all seems entirely too big. I could scarcely imagine starting from scratch.

But of course it’s not so bad. If my student sticks with it, she’ll learn just the way I did. She’ll dip into something—a fun little project or time-saving utility—and struggle, and struggle, and somehow get it working.

Along the way she’ll pick up accidental bookfuls of hard knowledge: the basics of HTTP and TCP, how servers work, what OOP is for, how to configure Apache and Nginx and Haproxy and Memcache and Mongrels, how caching works, what hashes and lists and integers and floats all do, why some languages type statically and others dynamically, how to use higher-order functions, how to do file I/O, what to do with pipes, the rationale behind MVC, what’s “cascading” about cascading style sheets, the wonder of LISP macros, how to slice images and minify Javascripts, what the DOM is and how jQuery tames it, how to manage code with Git or Subversion, who Knuth is, how to sort integers and find shortest paths…

And her brain will be invaded just like mine with all sorts of “soft” knowledge. She’ll become intimately acquainted with the bedrock principles of the craft. She will learn Not to Repeat Herself and that “clarity is better than cleverness.”

She’ll learn to pack complexity into data, not code. She’ll fuss over the names of things and aim high on readability. She’ll struggle to cut her problems at their natural joints.

She will develop an uncanny ability to scan API documentation for the precise methods she needs now and to skim for others that might come in handy. She’ll start to sense when some part of the problem she’s working on must have been solved by someone else, and she’ll know how to find and incorporate the stranger’s solution. Her eyes will start snapping to just the right line in error traces.

As her toolkit grows, so too will the space of possible programs she can build. She’ll increasingly find herself daydreaming about unborn projects, imagining their concrete mechanics.

She’ll progress from not really perceiving the distinctions among so many technologies and acronyms, to being scared by the plenitudes, to seeing them as so many variations on familiar themes.

All the while she’ll marvel at how little she knows, and not long after, at all she has to teach.