“Just Learn to Code”
You have reached an impasse in your life. You are looking for a way to better yourself mentally or culturally. Or you’re un- or underemployed, and you can’t seem to get your resume past the door. Or, alternatively, you are having to make drastic, far-reaching decisions about who you are professionally or academically, and what it is you want to do. Or you are happy where you are professionally, but you want to future-proof your happiness against shifting fields and job requirements. If any of those scenarios apply to you, and you have solicited advice from essentially anybody, you have likely been told “just learn to code.” It works for coal miners, your parents, and men in taupe blazers, so why not you?
And you have seethed, oh how you have seethed. It rankles: the “just” part implies that it is very easy: there must be some personal deficiency that explains why you haven’t done this already. Maybe you’ve missed some vital critical period for “coding acquisition,” and you will be an object of pity and scorn for the future coding-native generation, a digital feral child. The “learn to code” part implies a monolithic skill-set, with its own argot and dues and secret handshakes. And lastly, you’ve met programmers. You know what they’re like. You could learn to code, but you might want a family one day.
It is my contention that “just learn to code” is a really dumb thing to say, not least of which because nobody knows what it means. Or, rather, it can mean so many things simultaneously that it ends up carrying no information whatsoever. It’s verbal white noise.
This essay owes much of its structure and rhetoric to Wysocki and Johnson-Eilola’s “Blinded by the Letter: Why Are We Using Literacy as a Metaphor for Everything Else?” Throughout that work is a skepticism that neologisms like “computer literacy,” “digital literacy,” and “post literacy” are really speaking to a central metaphor. I am similarly skeptical of “learn to code” — I don’t think it picks out any single intellectual activity, or even points usefully to any central group of activities. In this work, I will lay out some of the “bundles” (to borrow terminology from “Blinded By The Letter”) associated with learning to code. Some of these bundles are coming from a place of naïveté and, at heart, politically icky. Others I think are laudatory, but not necessarily useful. In general, these bundles do not play well together, and we need to target our terminology and our pedagogy to more precisely separate the good from the bad.
Full Disclosure: I have a Ph-goddamn-D. in Computer Science. I code every day. I am in academia, so technically I am not explicitly paid to code, but it would be pretty hard to do my job if I didn’t. Sometimes my job is to teach other people how to code. Sometimes I code for fun, because I like it. It scratches some pretty core mental itches for me. Also, this essay is intentionally provocative and inflammatory. Okay? Okay.
Bundle 1: “Learning to Code” as Merit Badge
There actually is a Boy Scout Merit badge for programming. It is wildly unpopular (although it is gaining ground, finally beating out “Dog Care” in 2014). In general, by “merit badge,” I mean something where you follow the Boy/Girl/Lumberjane Scout process: somebody gives you a booklet about the topic, you do the activities described in the booklet, somebody signs off, and you get a token at the end saying that you’ve achieved some level of competency at Archery or Swimming or Nuclear Science or whatever. Technical certifications, computer science degrees, and professional titles are all, to some extent, merit badges in coding. Frequently, the pedagogy is teleologically oriented towards these badges: you’re doing it for the pay bump or the potential job offer at Google or Hooli, so who cares how much really sinks in.
The assumption here is that getting your merit badge opens doors for you. You can apply to high-paying jobs in the tech industry, hitching yourself to the tech boom, whose trajectory is always and ever upwards. And these skills are in such short supply, and high paying tech jobs so presumably ubiquitous, that tech dudes have the chutzpah to write stuff like this.
This bundle hurts pretty much everybody. It hurts teachers who think of computer science as a discipline of beauty and art and intellectual striving as opposed to, like, the 2010s equivalent of a correspondence course in Furby repair or something. It hurts learners who get all the right merit badges, but learn that the companies they want to work for are really looking for “10x” developers or “unicorns” or “rockstars” or “good culture fits” or some other phrase that, in essence, means “not you.” And that’s with the right badges! Less agile learning environments (such as high schools that have to target AP tests written for particular languages, or employers who prioritize training on legacy or proprietary or otherwise idiosyncratic systems) may give you badges that are completely useless anywhere else, or are so common that employers greet them with a shrug.
Bundle 2: “Learning to Code” as Shibboleth
Some jobs are iconic (read: stereotyped). There is a reason that the Village People dressed up as cops and construction workers, and not claims adjusters or dog walkers. I’d argue that programmers, for better or worse (largely worse), are similarly iconic. That’s why there’s a Computer Engineer Barbie and not an Actuarial Barbie.
Learning to code, in this bundle, means learning to “speak geek” — to be able to blend in culturally with what people expect from a programmer. It’s being able to give passionate arguments for or against particular programming languages, operating systems, browsers, package managers, or text editors. It’s being able to self-describe as a “hacker” with a straight face. It’s shit like this.
You could know a programming language inside and out, but still not be a “coder” by the standards of this bundle: a mere “dabbler,” perhaps. I’ve talked to people who have told me “I wish I knew how to code” despite having jobs where they regularly write SQL queries, construct test plans, and make macro-driven pivot tables. They program (in the usual sense) every day, but they think of “coding” as a quasi-mythical skill-set that they don’t possess.
The largest obstacle to being this kind of coder is therefore being able to convince people (including yourself) that you already are one! This means being acquainted with the right terminology. It means keeping up with the hottest languages and environments. It means developing your skill set with the larger programming community in mind (nobody I know is hiring exclusive Brainfuck developers, alas).
Many of these things have absolutely nothing to do with programming either in the abstract, or in the practice of software development. Many of the bits that are relevant are perfectly teachable in the same time frame that one would learn the other parts of a new job (“Here’s who you should contact in HR for benefits information, here’s our in-house coding style, here’s how we do version control, check stack overflow for anything else, have a great first day”).
There’s a reason why companies will often give you a “Google-style” technical interview where you are asked to solve problems in pseudocode on a (digital or real world) whiteboard. As with Edison tests, being able to remember on the spot what is (frequently) trivia about data structures and algorithms is meant to be a synecdoche for the larger skill of being a developer, giving hints as to how one conceptualizes and articulates problems, and how cleanly one writes code. Large parts of this bundle are similar in thought process: this guy is so articulate and passionate about node.js, he’ll be just as passionate and thoughtful with all of the code that he writes!
This strategy is pretty much straight up garbage, especially if one of your hiring goals is “hire people that aren’t exactly like me in terms of social and educational background.” In general, defining a “coder” in such a normative way is a recipe for chronic imposter syndrome, ballooning egos, and needless homogeneity.
Bundle 3: “Learning to Code” as Software Engineering
If you take a computer science class in school, or you take a course from Code Academy or some other magnet for autodidacts, you will likely learn a few things: a specific programming language, some general tools for programming, and some algorithms to solve specific problems. If somebody says “write me a program that does X,” you will hop to it and merrily type away.
This sort of individual problem solving has as much to do with professional programming “in the wild” as solitaire does to bridge. They are both games with cards, yes, but only in the latter will you get yelled at for not knowing that you shouldn’t have bid 3♥ if you didn’t have the points for it. Rather than “write me a program that does X,” software engineering is closer to “write me a program that does X, but it used to do Y, and make sure you don’t screw with any of the people that are trying to make it do Z, &c. &c.” Version control, project management, writing code that is readable, maintainable, and scalable: all of these things are not well integrated with how one typically learns a particular programming language. Even if it were taught abstractly as part of the standard CS curriculum, I’d argue that writing collaborative, large-scale code is something that you’ve got to experience for yourself before you can really get a grip on it. There’s nothing to compare to the “oh shit” of potentially breaking a build, and one will go to great lengths to avoid feeling that way again.
In general, this bundle asks you to think of coding as a practice rather than a skill. It’s not a thing you can “complete,” but something that evolves over time, experience, and practice: it’s like “learning how to play the piano” not “learning how to tie your shoes.” It is also fundamentally collaborative, which seems to be a problem for the model where one completes a Javascript bootcamp and then emerges butterfly-like from your non-coding chrysalis, ready to tackle the job market.
So how does one build up this sort of knowledge, assuming one is neither a) already employed as a developer nor b) involved in a higher level computer science program of the right sort? I.e., if we’re the kind of person that has just been told to “learn to code?” The general answers are: “get an internship” or “contribute to an open source project.” Unfortunately, getting a technical internship (especially one that pays, and lets you do meaningful development) is both rare, and tends to select for the people who already know what they are doing, instead of the people looking to find out what to do.
In general, I think contributing to open source projects is a more reliably useful way of building up this kind of knowledge. Even if you are not already a programmer, helping to write documentation, report bugs, and contribute to platforms like Wikipedia (markup languages are still coding!) are all things that at the very least get you in the same headspace as a collaborative software engineer.
However, not all coders are software engineers. Conversely, not all software engineers are coders: a manager with a whiteboard can get just as much software engineering done as a coder with a command line. And many of these skills are more about how to deal with groups of people more than they are about anything to do with computers. And computer science really doesn’t have a great track record at imparting those kind of skills. There’s a reason the joke goes: “How do you find an extroverted engineer? They look at your shoes, instead of their own.”
Bundle 4: “Learning to Code” as Mindset
Various academic disciplines give you access to tools that fundamentally change how you interact with the world. Before we get into computer science, we’ll tackle an older (and oft-maligned by the STEM crowd) field: literature. What does literature, as an academic discipline, give you that nobody else does? Among many other virtues, it gives you tools to examine how language can be used to create meaning. It gives you a wide base of knowledge and appreciation for literature from perspectives you may not have encountered as an unguided forager of books. Anybody can read a bunch of books, but not everybody is a literary scholar. The literary toolkit contains things like critical lenses, close reading, and hermeneutics.
Similarly, the computer science toolkit contains things like abstraction, recursion, and encapsulation. We should therefore, in this bundle, learn to code as part of the humanist project of self-cultivation, just to get access to these vital abstract thinking skills. We’d want to learn to code, in this sense, even if there were no computers around to use. It’s why, when Neal Stephenson needed a deus ex machina in his cyberpunk novel, he could think of no threat deadlier than an army of girls trained in computer science and martial arts. It’s the breathless Ted talk reasoning about why to learn to code.
The preceding paragraph, the attentive reader will notice, is exceedingly myopic. The “good bits” of coding (abstraction and logical thinking and so on) may not be unique to computer science (for instance, what about mathematics and music and art and…?), and the actual process of getting to them requires a great deal of preliminary effort that doesn’t look good at all. When, on their first day, a computer science 101 student sees:
public static void main(String[] args){
System.out.println("Hello World");
}They are not impressed by interleaving systems of mathematical calculation and great chains of formal systems. They see a bunch of syntax, idiosyncratic to a programming language that may or may not resemble whatever languages they will end up using for their own projects in the real world. There are 76 characters in that code block, and only 19 in the English language description of what the program does (“Print “Hello World””). All too often, the bits of syntactic sugar that surround a program are initially taught as just magical incantations to memorize and type exactly. What they actually do, and why they are necessary, is more advanced material. In general, getting to the “good bits” (for this bundle) of coding requires heaps and heaps of bullshit. Why, then, learn a specific programming language, when we can get all of those good bits from Flash games, or books, or Legos?
Conclusion
“Learn to code” is often said with the same somewhat condescending paternalism as “eat your vegetables” to a toddler, or the same sneer that one might say “learn to play” to ones’ poorly performing teammates in a video game. Other self-set goals for personal enrichment, like “learn a foreign language” or “learn to play a musical instrument” manage to call for self-improvement without sounding like personal attacks.
So what is our alternatives? Luckily, we have a whole constellations of different imperatives. Some of them are even actionable, measurable, or useful:
- “Learn how to write simple programs in language x”
- “Learn how to automate something that you typically do by hand”
- “Complete a programming course in school [or your web platform or MOOC of choice] about x”
- “Contribute to a collaborative software project”
- “Learn how to make a program you think is cool”
…
And so on. The specifics aren’t too important, largely because small goals like these tend to be a) fun and b) self-reinforcing. One of the addictive things about computer science is when things start to click, and you can tackle problem after problem. Very few of the pedagogical dominos need to start falling before you can start to do cool, interesting, or valuable things (that’s the power of abstraction).
Learning To Code, the monolithic, life-long project, by contrast, is neither small nor self-reinforcing. It is difficult to get a grasp on. It’s a chore, and if your bundles don’t match up with the bundles of your teacher or fellow students, it can be discouraging or even infuriating. So stop asking people to do it, unless you really know what you mean.
