This might seem pretty redundant considering the whole point of this website is to help you learn how to code. I hope that the tutorials are useful, but I also know how hard it can be to navigate. How do you get started? What language do you learn first? What do you do with it? How much time do you spend on each topic? How do you accomplish your ultimate goal?
This guide is my attempt at answering some of those questions. It’s a meta-guide on how to use Happy Coding, and a more general guide on how to learn coding.
I’m personally very motivated by being able to share the stuff I create. That’s part of why I started Happy Coding, and I also post my work on Twitter and Etsy. So before you start diving into code, take a second to think about where you want to document your journey.
This could be posting screenshots of your work on social media. Or you could create a GitHub profile README or use GitHub Pages to create a portfolio page. You could also start by learning HTML and creating your own website.
It doesn’t have to be fancy. But I find it really important to be able to take something I’ve been working on, call it finished, and then put it out in the world. I never expect to become rich and famous or anything, but it’s cool to be able to point to something that I created. That helps keep me motivated, which I think is super important if you’re teaching yourself how to code.
I would love to hear from you, so please also post your work on the Happy Coding forum!
I personally recommend starting with p5.js because you don’t have to download or install anything to use it, and you can share your work as an interactive webpage without knowing any HTML. Or you might start by learning HTML, especially if you want to create your own portfolio page. Or you might start with Processing, especially if you already know some Java.
Learn how to create p5.js sketches!
Should I use p5.js or Processing?
Learn how to program in Processing!
Learn how to use HTML to create a webpage.
But believe it or not, it doesn’t really matter which language you learn first. Coding languages are a lot like tools. Learning about one tool doesn’t mean you can’t learn about any other tools. In fact, learning how to use a hammer makes it easier to learn how to use a screwdriver. Coding languages are the same, and most programmers use a mix of many different languages.
My point is, don’t get so caught up in deciding where to start that you never start at all. In other words, avoid analysis paralysis! If you aren’t sure where to start, start with p5.js. Everything you learn there will transfer to any other language you learn later.
Coding is a craft, and just like any other craft, the only way to learn it is by doing it. Think about it this way: who is going to be a better artist, somebody who spent a day reading a bunch of articles on different art techniques, or somebody who spent a month painting every day?
Learning how to code is the same. If you’re skimming through the tutorials and then moving on to the next one, you aren’t going to learn much. One of the best pieces of advice I can give you is to slow down. Reading a single tutorial itself probably won’t take you more than an hour, but to really internalize what you’re learning, spend at least a week writing code yourself to practice what you’re reading.
Taking your time is especially important if you’re teaching yourself. In a classroom environment, your teacher sets the pace, gives you practice with homework, and checks that you’re learning through tests. If you’re learning on your own, all of that becomes your job. If you don’t take your time to really practice what you’re learning, then you won’t learn anything, and you’ll come out of it with a feeling of “now what?” instead of with knowledge that you can use.
See the next section for ideas on how to give yourself more practice.
Like I said, after you read a tutorial, you should spend at least a week writing code that practices what you read. Try to give yourself a goal that serves as an excuse for practicing that concept. The homework section at the bottom of most tutorials is a good place to start.
You might also check out CodePen’s weekly challenges, and of course please don’t hesitate to post in the Happy Coding forum if you want some other ideas. The important thing is to give yourself a project to work on, which is really an excuse to keep learning.
One of the most common mistakes a lot of novices (and non-novices!) make is trying to do too much at one time. It’s hard to know how long something takes, especially if you’re learning by yourself. So it’s tempting to bite off more than you’re ready to chew. Trying to do too much leads to a frustrating cycle where you feel like you aren’t making progress, which drains your motivation, which only makes you feel more frustrated.
Instead, try to start small. Give yourself goals that you think will take about an hour, because those will usually end up taking a week. If you start with a goal that you think will take you a week, those will often take you a month!
Another important skill is breaking problems down into smaller steps and then taking those steps on one at a time. In other words, don’t try to do everything all at once. Instead, work iteratively so that each weekly goal gets you closer to your larger goal. If your end goal is to create Instagram But For Cats, start by showing a single static cat image. If your goal is to make digital art that ends up in a gallery, start by displaying some shapes. If your goal is to make Minecraft But For Cats, start with Pong For Cats. Each of those smaller steps can probably be further broken down into even smaller steps!
Like every creative process, coding never feels quite done. The project you’re working on will never be perfect or finished. There will always be one more thing you can add, one more brush stroke, one more line of code.
Ship it anyway.
Shipping it means accepting that you’ll never be done, slapping a “version 1.0” label on it, and putting it out there in the world. I started this guide by asking you to think about how you wanted to share your work. This is where that comes in handy. Even if you don’t feel finished, even if there’s more you want to do, ship it. Upload that screenshot, post that blog article, share a link on the forum.
And then move on to the next week. Or if you want more practice, spend another week getting more practice. But don’t fall into the trap of waiting until you’re “done” to move on, because you’ll never feel done.
As painful as deadlines can feel, they’re very useful motivators. In a classroom, homework due dates and tests provide deadlines, but if you’re learning on your own, you have to make your own schedule.
I think a reasonable cadence is to say that you’ll post whatever you have so far at noon on Sunday. Pick whatever day and time makes sense, but the important thing is to give yourself a “pencils down” time. When you reach that time, you’re done, even if you don’t feel done.
I also sometimes give myself a daily challenge, where I say I’ll post whatever I have before I go to bed. I might stay up a couple hours later than normal, but at the end of the day I’ll have something to show for my work, and that’s the important part. It doesn’t matter that it’s not perfect, because it’ll never be perfect.
Feature creep is that voice in your head that says “wouldn’t it be cool if you added this other thing?” whenever you’re working on a project. Listening to that voice is dangerous, because it means you’re constantly chasing the next cool-sounding feature instead of finishing what you already started.
I won’t tell you to ignore that voice, because I think that voice is where a lot of creativity comes from. But I will recommend delaying that voice. By that I mean, whenever you have an idea for a cool thing you could add, write it down! Then go back to the task you’re already working on. When you finish that task (and post it), take a look at your list for possible next steps.
You’ve started coding, you’ve read through a tutorial, you’ve spent a week practicing what you learned, and you’ve shared your work when you hit your deadline.
Now do it again.
Move on to the next tutorial, or try implementing the next thing on your feature creep list. Rinse and repeat. Even if you choose to spend another week getting more practice with the same concept, the important thing is to keep iterating. Take your time, but don’t bang your head against the same problem for too long. If you’re stuck, get help! Ship what you’ve got so far, and then do the next thing, even if that next thing is another round of practicing the same concept again.
This iterative process is the driving mechanism behind how I learn, so if you’re wondering what it looks like to be a coder, this is it. I don’t think that learning ever ends. I’ve been learning at least one new thing every week ever since I started coding, and I’m pretty sure that’s going to continue for the rest of my life.
By applying the same learn-practice-post process every week, you’ll quickly build up your knowledge, and you’ll have a collection of posts that document your journey.
Coding isn’t a series of facts that you can memorize. It’s a process that you have to learn, and the only way to learn it is by doing it over and over again. This is exactly how most skills work: playing a piano, throwing a basketball, painting a picture. The only way to learn how to do these things is by doing them. Whoever said “practice makes perfect” wasn’t lying!
That’s why you won’t learn much by skimming through tutorials. Even if you’re memorizing everything you read (and if you’re like me, chances are you aren’t), you aren’t getting any practical experience. It doesn’t matter if you’ve memorized the syntax of an
if statement if you don’t know when to use one. And that type of knowledge comes from practice.
Coding involves a lot of other skills that you can’t really learn by reading about them. Skills like breaking a problem down into smaller steps, time management, scoping, reaching deadlines, and staying motivated. Smarter people than me have called this metacognition or learning how to learn. That’s what you’re really learning when you learn how to code, and it’s way more important than memorizing syntax. And the only way to learn that is through practice, practice, and more practice.
So after you read through a tutorial, give yourself a weekly project, use it as an excuse to learn and practice a concept, and then post what you have so far! And then repeat that process over and over again.
Congratulations, you are now a coder!
I spent a lot of time talking about taking your time, establishing goals, scoping your work, and shipping your projects even though they never feel done, because I think that the most common mistakes that new coders and self-learners make is rushing through tutorials and then trying to do too much. This drains your motivation, because you end up not learning the process, which is actually the part that matters.
I’m hoping that the above advice helps you frame the rest of the content on Happy Coding. And as always, please please please come say hi on the Happy Coding forum when you have questions or want to share what you learned this week!
Happy Coding is a community of folks just like you learning about coding.
Do you have a comment or question? Post it here!
Comments are powered by the Happy Coding forum. This page has a corresponding forum post, and replies to that post show up as comments here. Click the button above to go to the forum to post a comment!