Note from the editor: The following is a guest post by Clive Thompson (@pomeranian99), a journalist who’s written about technology and science for two decades. Clive is a longtime contributing writer for the New York Times Magazine and a columnist for Wired.
In his guest post, Clive outlines the most important lessons he learned teaching himself to code after interviewing 200+ programmers for his new book Coders: The Making of a New Tribe and the Remaking of the World.
So, you want to learn to code.
Join the club! We live in a time when, as the venture capitalist Marc Andreessen famously put it, “…software is eating the world.” So the people who know how to program are in a catalytic spot; they can make things happen. Maybe you’ve watched this from the sidelines and thought: Huh. Could I learn to do that? Perhaps you’re out of school; maybe you can’t afford either the money or the time to go back and do a four-year degree in computer science. You’ve seen a zillion of these online tutorials in coding. Could you just sort of, well, teach yourself?
The short answer is: Sure you can.
The longer answer is… the rest of this essay.
The reason why I think you can do it is that I’ve met tons of people who did. I’m a science journalist who spent three years interviewing about 200 programmers for my upcoming book Coders: The Making of a New Tribe and the Remaking of the World. The bulk of them had studied computer science, but a surprisingly significant minority were self-taught. They were artists or accountants or speechwriters or marketers or musicians or carpenters or stay-at-home parents or people from just about any walk of life, but they’d gotten interested in coding, buckled down, and learned.
They inspired me, frankly, to dive in and teach myself. I’d gone my whole adult career doing essentially no coding. As a teen, back in the ’80s (I’m old, people), I’d learned some BASIC on those computers you plugged into your TV. It was a blast—I made little (terrible) video games and insult generators and bits of computer music, but I didn’t get very far because my mother refused to let our family own a computer. (“He’ll just sit around playing games all day long,” she told my dad.) So I never studied coding and, instead, did degrees in English and political science. As an adult, I’d really only tinkered with a bit of HTML and some web pages. When I started thinking about learning to code a few years ago, I had a day job and couldn’t study full time.
So I decided to teach myself in my spare hours. I wasn’t looking to become a full-time coder, mind you. I had no visions of creating some app and scoring boatloads of VC money. I was just curious to find out: how learnable was this, as a skill? Could I do it well enough to make software that was, at a minimum, useful for me?
The answer was, on all fronts, yes.
I learned a ton, and now I very frequently write code to help me in my job as a journalist and book author. I’ve written little scripts and programs that make my work and personal life easier. I’ve also discovered I enjoy it—it can be an absolute blast, intellectually and creatively.
Along the way, I gathered some hopefully-useful lessons for you. Some of them from my own experience and some from talking to experts—those who teach programming and some full-time coders who taught themselves.
So the advice I gleaned, in order, is:
#1) The online world is your friend. Start there.
It’s never been easier to get started learning to code because there are dozens of free-or-cheap courses online. If you’d tried to do this even a decade ago, the pickings were slim. Now, it’s a cornucopia. Within five minutes of reading my list, you could be starting an online course.
A word of warning as you dive into online courses? Buyer beware: “Most of the stuff that says it’s ‘Great for a beginner’ is not,” as my friend Katrina Owen—a self-taught coder who works as an engineer for GitHub and founded Exercism, an open-source project that offers coding challenges to help sharpen your chops—says. She’s right. I’ve seen a ton of “tutorials” that are supposed to be for newbies but are written erratically. Half the time they’re great, patiently walking you through material, then half the time they assume you already know what an object or an IDE is. If you try these, you’ll wind up feeling frustrated and thinking that it’s your fault you don’t understand things, but it isn’t. So find recommendations: Read online reviews of a course, use my suggestions here, ask friends.
#2) Don’t stress over what language to pick.
Don’t get bogged down picking the “perfect” language to learn. Your goal in the early days is just to become familiar with the basic concepts of coding, which are similar across all languages.
Actually, you may want to avoid Googling “What coding language should I learn?” because you’ll immediately find yourself deep in the sprawling flames wars that coders engage in over Which Language Sucks/Rocks. These arguments are a) frequently nuts and b) to the extent that they have any meaning, nothing you need to worry about right now.
#3) Code every day.
This is a big one. You should try to do some coding every day—at least, say, a half hour.
Why? Because this is just like learning Spanish or French: Fluency comes from constant use. To code is to speak to a computer, so you should be speaking often. Newbies often try to do big, deep dives on the weekends, but that’s too infrequent. “Programming languages are still languages, so attempting to learn them only on weekends doesn’t train your ability to use them naturally. It requires daily practice and study,” as Zed Shaw told me. But you’re busy, so how are you going to find time to code every day? Well, Shaw argues, take the time you normally allocate for something fun—watching TV, going out with friends, video games, watching sports—and use it instead to code daily. “It’s better to do one hour a day then ten hours on Saturday,” argues Avi Flombaum, who runs the Flatiron School, one of the first coding bootcamps, and now a WeWork company.
They’re right—this was precisely my experience. When I was doing a bit of coding every day, I found I could much more quickly grasp key concepts. But if I stopped for a few days or, every so often, a few weeks, when a crush of work in my day-job and a load of personal-life responsibilities arrived, it was like wiping the slate clean. I’d come back to work on a coding project and I’d have forgotten a shocking amount of basic stuff.
Related to this advice, it’s worth noting that learning to code—to the point where you can build something useful for yourself or others—isn’t going to happen quickly. A while ago there was a vogue for books with titles like Learn Java in 10 Hours, which is frankly insane. It’s more like, “Learn to code in ten months,” (or, as the longtime Google programmer Peter Norvig once wrote, “Teach Yourself Programming in Ten Years”.) It was a few months before I was beginning to make little scripts and web tools that actually accomplished a useful task for myself.
And while getting a half-hour a day is useful, if you can do more, do more. Programming typically requires immersion: When you’re trying to understand a new concept, you’ll do a lot of staring at the screen, trying to grasp or visualize or apprehend the flow of logic or data through a snippet of code. Very often I’d find I would sit down to learn something in an evening, thinking I’d spent 30 minutes, then get stuck—and two hours would go by before I’d get unstuck. It isn’t always easy when you’ve got a busy life, but free up as much time as you can.
The trick here is finding a good bootcamp. It’s an unregulated field, in which high-quality ones with solid track records of grads finding jobs exist cheek-by-jowl with dodgy, fly-by-night ones. In NYC where I live, some well-regarded ones are Flatiron (which also operates in eight other locations, including Houston, Washington and Atlanta), Grace Hopper (which also operates in Chicago), and General Assembly (which also operates in 19 other locations around the US, such as Austin, San Francisco and Boston). In San Francisco, it includes Hack Reactor and App Academy. It’s very much a city-by-city scene, though, so do your local research if you go this route; SwitchUp is a useful resource here.
#4) Automate your life.
When people think, “I’m going to learn to code,” they often assume it needs to end in making a product—some app like Facebook or Grubhub or Uber.
Sure, that could happen. But honestly, the more practical reason to learn to code is much simpler, more mundane, but much more personally powerful. You can very quickly learn to automate boring things in you life.
That’s because computers are amazing at doing dull, repetitive tasks. They’re also great at being precise. Since we humans are terrible at doing dull tasks and quite bad at being precise, this makes us a match made in heaven. So one enormous pleasure in learning to code is that you begin to see how you can automate many difficult, onerous tasks.
For example, when I’m reporting I often find a great speech on YouTube, and I want to copy and save the automatic transcription of it. The problem is, the transcriptions that YouTube generates are messy—every other line is a piece of timecode. So when I’d cut and paste them into a research file, the file would be long and hard to skim. I could go through and delete every other line, but yikes, what a hassle!
So instead, one evening I quickly wrote a dead-simple little web tool that lets me paste in a YouTube transcript, and, with a button-push, clean up the transcript, removing the timecode lines and rendering it into a single paragraph. It’s much easier to read that way.
I’ve written tons of other scripts to automate boring things. My youngest son once ran into a problem: He wanted to get his homework done quickly after getting home from school, and his teacher would post it to the school’s web site, but sometimes she’d delay. So he’d sit there, refreshing the page every so often, waiting for the homework to post. To automate that, I wrote a little web-scraper that would check the page every five minutes, and once it detected the homework was posted, it’d shoot a text message to me and my son—so he could now do whatever he wanted, knowing he’d get an automated alert. These days, I’m working on a little script that registers where I’ve parked the car on the streets of Brooklyn (where I live) and sends me an automated reminder when I need to move it before I get a ticket.
This is the secret value of coding, for me. I’m not going to quit my job to build a software company or get hired as a coder. But coding makes me more efficient, more empowered, at my job and in everyday life, often in weird and delightful ways. Odds are this will be true of you, too.
But it is. And, indeed, this sort of coding—tucked into the corner of your existing work—is insanely powerful. Rather than quit your job to become “a programmer,” learn some coding so you can become much more valuable at your existing career and maybe move up in pay. There are people who do that all the time, as Zach Sims, the founder of Codecademy, tells me.
“Coding,” he jokes, “is marketed poorly.”
#5) Prepare for constant, grinding frustration.
Coding is brutally, punishingly frustrating.
Why? Because the computer will do whatever you say—but only if you are perfectly, utterly precise in your instructions. One small mistake, one misplaced bracket, and odds are high the whole shebang stops working.
“Programming is a constant stream of failures thrown at you by a computer that does not care how you feel,” Shaw notes.
This is the fulcrum around which all coder experience, and all coder psychology, pivots. After interviewing scores of developers for Coders, I’ve come to an interesting conclusion: Being logical and systematic is not, at heart, what makes someone good at programming. Sure, you obviously need to be able to think logically, to break big tasks down into tiny steps. That’s a prerequisite. But if you asked me what’s the one psychological nuance that unifies all the coders I’ve interviewed?
They’re all able to handle total, crushing, incessant failure and roadblocks (at least, at the keyboard.) People think that programmers code all day long; you look at Hollywood movies, and the hackers’ fingers are flying, pouring out code onto the screen. Looks fun, right?
Nope. Most coding goes like this: You write a few lines of code, something intended to do something fairly simple, then you run a test on it, and… it doesn’t work. So you try to figure out what’s wrong, isolating sub-parts of the code and testing them, or Googling the error messages the computer spits up, in desperate hopes that someone else online has written about this particular problem. And quite often I’d discover, after long periods—minutes, certainly; often hours, sometimes days—that the problem was my own error, and an aggravatingly “how obvious” one: A tiny typo, a missing colon. Nothing has ever made me feel like an idiot so regularly, so routinely, than computer programming.
And this psychological storm doesn’t really let up, no matter how good you get or how long you code. I’ve spoken to top coders for places like Facebook or Google or Baidu, and they’ll tell you the same thing: They spend a lot of their time trying to figure out what’s wrong, why things aren’t working. They don’t make the stupid newbie mistakes I make, clearly, but since they now work on very complex systems, they run into very complex problems. Either way, they face grinding frustration, too.
Now, why would anyone endure such a grind? Because of the flip side. When you finally figure out the problem—when you fix the bug, and things start working—there’s a sudden, narcotic rush of pleasure that’s almost unlike anything you’ve ever experienced. It’s delightful, people. There are few things in life that give you that absolute sense of mastery and joy. My wife got used to hearing me give a sudden whoop when some busted piece of crappy code I’d been tinkering finally twitched its Frankensteinian eyes open and came to life.
It’s almost cheesy now to talk about the “growth mindset,” the idea that you should approach a new skill assuming it’s going to be hard, but it can be learned. But this is crucial with coding. The frustration will never let up; the better you get, the farther you’ll reach, and the more fiendish will become your bugs. But coding isn’t some mystical act. It’s just sheer persistence and work ethic. “It’s hard, but it’s not impossible,” as Owen says.
This is why, also, try not to get intimidated by other people’s code—or by programmers who breezily boast online, when you read a thread on Stack Overflow about how obvious some concept is. Ignore them. Everything in coding is hard the first time you do it. “Never compare yourself to others and don’t take online criticism personally,” says Lydia Hallie, a 21-year-old woman in Stockholm, who taught herself to code as a teenager. “The fact that you’re struggling when you’re teaching yourself how to code is completely normal and doesn’t say anything about how good of a programmer you’ll be later.”
#6) Build things. Build lots of things.
When you’re learning to code, you need to start trying to build things—real pieces of code you can use.
Certainly, the online tutorials and books are good for giving you the basics. But what really teaches you how code works is when you try to make a piece of software that does something. That’s when you finally grapple with what you do and don’t know. It’s the difference between learning French phrases from a book or in class, then going into a restaurant and ordering a meal.
One extreme example of this “build stuff” approach is Jen Dewalt. Back in 2013, she was a designer with a background in fine art but no real experience coding, when, at age 30, she decided to teach herself programming. To make it serious, she decided to make a website a day… for 180 days. At first they were incredibly simple pages, like a button you could click to change the background color. But within a few weeks, she’d learned enough to make little interactive games or a clock that displayed the time in words. And by the last few days, she was doing complex stuff, like a mood analyzer that would count how often hashtags like “#awkward” were being used on Twitter, in real time.
“I highly recommend starting with small, tangible projects,” she told me. If she wanted to make something, she’d use snippets of code she found at coder sites like Stack Overflow, not worrying if she didn’t understand them very well, so long as they worked. (Though she’d always type in the code, herself, to work it into her muscle memory. Zed Shaw suggests this, too. Don’t cut-and-paste code if you’re borrowing it from someone else. Type it in yourself; it forces you to ponder it a bit more deeply.)
Dewalt’s main advice? “Just Fucking Do It (#JFDI)!” The sooner you start trying to make things, the quicker you learn. You certainly may not have the ability to do what Dewalt did; she saved enough to not work for months, so she could learn coding all day long. (Not an option for me.) But the general idea—do little, tangible things—is key.
#7) “View Source”: Take other people’s code, pick it apart, and reuse it.
If you wanted to learn how a clock works, you’d disassemble it and try to reassemble it, right? That’s how the pioneering programmer Grace Hopper’s mind worked. As a curious kid, she took apart so many clocks, her parents bought her one just to disassemble and reassemble.
“That’s how open source works,” as Chris Coyier, Codepen’s founder, tells me. You see something great, and you reuse it. “You’re in the clear, not just legally but morally.” Indeed, the vast majority of software you use all day long relies heavily on reused, open-source code—something someone grabbed and modified for their own purposes.
Also, starting with an existing app and making it do something new, something you uniquely want, can help prime your pump and make it less intimidating to begin a piece of code that stretches your boundaries. “It’s good when you’re not starting from a blank page because whenever I’m getting into learning a new language or a design pattern, when I started from a blank page I was overwhelmed and paralyzed,” as Jenn Schiffer, the director of community engineering for Glitch, tells me.
#8) Build things for you—code you need and want.
As I learned more coding, I realized I could make a lot of little pieces of software that were useful for me.
Here’s a funny one: I made my own Pomodoro timer. You may have heard of the “Pomodoro” technique, where you set a timer for 25 or 15 minutes and work in a focused way—not checking email or distracting yourself—until the dinger goes off, at which point you take a short break. It’s a great concept, and I used to use various Pomodoro timers online. But they all had one problem: They generally forced me to pick a quantum of time that was 15 or 25 minutes.
And, well, my procrastination problems were worse than that. I wanted a Pomodoro timer that would let me work for… five minutes. Or three. Or one minute. When I was truly avoiding work, hell, working for one damn minute would be a victory, people! But none of the Pomodoro software was designed for someone as horrifically work-avoidant as me.
So I thought, to hell with it, I’ll code my own. I used Python to make a simple “command line” timer that lets me pick precisely how many minutes I could work. (I can even pick increments: 10% of a minute! Six seconds!) And to make it funny and witty to use, I wrote a ton of cheery, you-go messages for when I finish each work session and coded it so the robotic voice of my computer speaks it aloud. (“Rock and roll,” the computer intones. “Boo ya.”) It is a weird, crazy piece of software, utterly specific to my needs. That’s precisely why no one else on the planet was going to make something like this! And why I made it for myself. It’s a customized app for an audience of one: Me. And wow, was it useful! I started using it on a daily basis; I still use it a few times a week, when I feel myself starting to slack off.
The more I coded, the more I found things I could build to make my work easier. I made web scrapers that would auto-grab material I needed off websites for journalistic research. I made Twitter scripts that would archive any links I posted to Twitter every day and email me a summary. When I got worried that I was too frequently using italics while writing my book (it is a bad habit, stylistically) I wrote a Python script to analyze the text, pull out every italicized word, and deliver me a long and humiliating list.
The point is, one of the best ways to motivate yourself to learn coding is to build little apps that actually do something you need done. It’s deeply motivating. If you’re coding in an abstract way, doing tutorials, it’s easy—when you get stuck—to think, ah, screw it, and stop. But if you’re actually building a tool you’re going to use? It pushes you to go further, to work past the frustration and the blockages.
#9) Learn how to learn.
While researching my book, I visited with the programmer who’d created a Y Combinator company that had just landed its first series of funding. “What’s the secret to being a good coder,” I asked him? He laughed.
“It’s having good Google-fu,” he said. Sure, he’s a programmer, so he writes code. But what many programmers do much of the day is sit around Googling things, reading up, trying to figure out how to do something—how to solve a problem, how to kill a bug that has stopped them in their tracks.
So when you learn to code, your core skill is going to be constantly learning and constantly relearning. That’s true in the short term and the long term. Over the years, new languages and frameworks always emerge, and old ones evolve. “Being a programmer basically means you’ll be an eternal student,” as Lydia Hallie told me.
#10) Reach out to other coders.
Learning to code can be pretty isolating—it’s hours of just wrestling with the computer. And while it’s good to try to figure things out, yourself, sometimes the fastest way to get unstuck is to ask someone else, How the heck does this work?
So nearly everyone I know who taught themselves to code built some sort of social network around coding. freeCodeCamp’s Larson urges it: “Hang out with other developers. Go to tech talks and hackathons, and hang out at startups and hackerspaces. This will help you make valuable connections and stay motivated during the long process of learning to code,” he told me. If you live in a really remote region or don’t have the mobility to find people face-to-face, try them online; freeCodeCamp and Glitch both have active forums, and sites like CodeNewbie have everything from a Slack forum to regular Twitter chats, where neophytes talk and connect.
Frankly, I wish I’d done more of this socializing. I too often spent time grinding away at a problem, myself, instead of asking for help. When I did talk to other coders about problems I was having, inevitably they’d suggest an approach that helped.
Clive’s new book Coders: The Making of a New Tribe and the Remaking of the World will be available on March 26th.
Read more: tim.blog