Ten Lessons I Learned While Teaching Myself to Code

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.

Enter Clive…

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.

Me, I decided to learn some JavaScript, since it’s a language that powers the web. After reading reviews and canvassing some recommendations, I started with the JavaScript lessons at Codeacademy, which begin very much at zero, assuming a newbie knows essentially nothing about programming concepts. Each lesson gives you a bit-by-bit primer on some part of coding—like assigning data to variables and using if-then statements—then challenges you to do something simple with it. After a few weeks using it, I read some blog posts touting freeCodeCamp, a different site for newbies, which integrates JavaScript alongside learning HTML and CSS, the languages for making web pages. I bounced back between the two tutorials, finding that their different approaches to teaching the same thing helped to cement the basics in my mind.

I didn’t stick to one language, though. I’d also heard that Python was a good language for neophytes, easier to pick even than JavaScript; and it’s used a lot in data analysis, something I was intrigued by. This time, instead of doing an online tutorial only, though, I used a book—Zed Shaw’s Learn Python The Hard Way, which many coders highly praised online. Indeed, while doing these online courses, I also amassed a small collection of paper books, like Crash Course in Python, Automate the Boring Stuff With Python, and Eloquent JavaScript, all of which were really useful: They were fast to flip through and refresh a concept in my memory. There are a ton of resources online—the instant you forget how to reverse-sort a list in Python, you can Google it—but it turns out paper books are still very useful. A good book like Shaw’s has been organized specifically to structure info about a coding language so it makes sense.

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.

“If you can learn one programming language, you can learn the other ones, and where you start doesn’t matter nearly as much as you might think,” as Quincy Larson, the founder of freeCodeCamp, told me. So pick one—the common ones for newbies are things like Python, JavaScript, Ruby, or, say, Microsoft’s C#—and dive in. You can switch around later or even, as I did, try a few and see which ones “take” better with your style of thinking. (Me, I prefer writing Python—it’s prettier, to my eyes—but JavaScript is more useful for building the web tools I use in my work, so I’ve stuck with both.) “Stop looking for the perfect coding course,” advises Madison Kanna, who taught herself programming at age 23. “Just pick a curriculum and stick with it.”

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.

Now, there’s one big exception to my rule here. If you’re learning to program specifically because you’re sick of your job and want to retain for full-time coding work, as fast as possible? Then your choice of language does matter. You want to match it up to market needs—specifically, your local market, notes my friend Saron Yitbarek, a developer and the founder of CodeNewbie, a podcast about programmers. So research your local job scene: What types of entry-level coding jobs exist, and what languages and skills do they ask for? Then find tutorials and books that will lead to those skills. “Find the jobs that you want, and then reverse engineer your curriculum,” she tells me.“ Too many people go, ‘Oh, I heard about JavaScript. Now I’m going to learn JavaScript.’ And they realize there are no JavaScript positions anywhere where they live. Then they’re stuck in a community that really wants them to learn .NET,” a Microsoft framework, “and they didn’t take the time to learn .NET.”   

#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.

For sheer density of learning, one option to consider—if you have the money and time—is a bootcamp. These are crash courses, typically several months long, where you study programming all day (and often into the evening) in a formal schooling environment with instructors and classmates. (A good community college can offer similar courses.) Bootcamps aren’t cheap, averaging over $11,000 in tuition, though some defer tuition until you get your first coding job. Their great upside is that they give you a curriculum: “…it takes away ‘decision fatigue,’” notes Flatiron’s Flombaum. Teaching yourself to code on your own, requires endless decisions: Should I keep learning this language? Which JavaScript front-end framework should I try? “Whereas here you have someone making those decisions for you, so you can just focus on learning,” he notes.

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.

“Don’t learn to code, learn to automate,” writes the coder Erik Dietrich. This is bang on. Nearly every white-collar job on the planet involves tons of work that can be done more efficiently if you know a bit of coding. Maybe you can automate collecting info for reports; maybe you can automate dull, routine emails. (I’ve done that. Gmail makes it easy with built-in JavaScript.) Before Katrina Owen became a coder, she was working as a secretary in Paris and would build bits of software that automated parts of the office workflow: She made it so employees could upload their spreadsheets to a form, and it’d pick apart the spreadsheet and input the info into a database. It was insanely valuable—though, as she notes, “I had no idea what I was doing was coding.”

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.

Now, when I say “build things,” I don’t mean: Build the next Facebook or Snapchat—heh, no. It can be something tiny, something weird, something small—but it’s something you can use, or show to someone else. For example, early on while learning JavaScript and HTML, I started building little web apps that would do funny things like autogenerate surrealist Pokemon names (to amuse my kids); the night of the 2016 election, I was so stressed out I wrote a little script that just flashed a variety of zomg messages on the screen, so I could externalize my nervousness and have the computer freak out for me. These were all small and silly, but they had to at least function, and when you have to make something function, that’s when you learn.

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.

So it is with code. When you’re building stuff, you don’t need to start from scratch. You can grab things that already exist, rip them apart, and see how they work. It’s a superb way to learn. For example, very early on in my coding tutorials, I wanted to make a little web page to decode and encode secret messages for my kids, but I honestly hadn’t yet done enough HTML or JavaScript to figure this out. So I went to Codepen.io—a site where people post little web doodads and where you can inspect and reuse any of their code. I found a couple of text boxes that worked more or less the way I wanted and added in some secret-code decryption scripts. Presto: I had my project done. And by poking around in someone else’s project, I learned a bunch of useful new things about using JavaScript and HTML.

Later on, when I was looking to learn how to set up Node, a type of JavaScript used to run web servers, I started using Glitch. It’s like a server version of Codepen: There are tons of projects you can grab, remix and tinker with. I wanted to make a Twitterbot that auto-generates haikus, so I grabbed an existing Twitterbot on Glitch and started poking around in the code. By now, I understood enough JavaScript to be able to figure out what part of the Twitterbot I needed to rewrite, injecting my own function that takes 1,000 lines of haiku, randomly picks three, and squirts that out to Twitter as an insta-poem. It was a terrific way to get started. If I’d had to start from scratch, I’d never have done it.

“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.

By the way, this isn’t just about utilitarian tools. I also discovered I loved using P5.js (a “library” of JavaScript) to make little bits of interactive art, merely for the pleasure of making something pretty or playful. This is as good a motivation as any for learning to code, says Daniel Shiffman, a professor at New York University’s Interactive Telecommunications Program, who makes fantastic learn-to-code videos (including some for P5.js that I learned from). Shiffman tells me that one great way in to coding is to take something artistic you like—music, drawing, games, wordplay and text—and learn programming that works within your field.

“It’s useful to learn programming in the context of applying it to something that you’re already passionate about,” he says. If you make music, try learning Sonic Pi, which lets you program tunes. If you dig art, learn P5.js or Processing. If you like games, make one with Phaser, also based on JavaScript. Approaching coding as a fun, creative hobby demystifies it. “It’s like the way you take up knitting or join a band. You find your local community of people who are hanging out in a coffee shop learning to code, just to have fun, and an experience where you don’t know where it’s leading—as opposed to, hey, I need to memorize the top five sorting algorithms so I can pass my Google interview.”

#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.

And frankly, given how much there is to know, a lot of programmers tell me they’re constantly Googling even pretty basic stuff—like different ways to sort or chunk a list. They might have done it hundreds of times before, but there are so many little fiddly aspects of the languages they use that it feels weirdly inefficient to use their brains for rote memorization because they can just Google whatever rote knowledge they need to quickly recall. “I’d call myself a JavaScript expert,” as Glitch’s Schiffer tells me, “and I would say I can’t remember any string-manipulation function because I can just look it up.”

(I was so deeply relieved when she said that! Me, when I’m writing JavaScript and need to find the length of a string—i.e., how many characters in “Clive Thompson”?—I look it up. Every. Single. Time.)

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