So you want to learn how to program?

Introduction

This post is for people who want to learn how to program but don't know where to start. I won't talk about the specifics of any particular language; this is more about getting you into the right mindset.

As for me, I've been programming professionally for many years, five of which were live-streamed on Twitch, so I've gotten my share of questions on the topic. The most common ones are:

Question: can anyone learn how to program?

If you can understand this blog post, then you can learn how to program.

Question: does programming involve a lot of math?

From a practical perspective, no. Programming is entirely based on logic, and while I do look at logic as being part of math, it's not the kind of math that people usually mean (e.g. calculus). Still, basic math skills and algebra will help.

For another point of view, think of a programming language like a human language—just because you know English doesn't mean that you can speak with authority on any topic! Programming is the same way; you may need to know biology in order to make medical software, music theory to code a sequencer, and math for data analysis.

Setting expectations

Without the right expectations, it's easy to get demotivated before you can build any momentum. The biggest expectation to set up-front is that you probably won't be making interesting programs for a while (at least a month or two). They'll more likely be small, console-based programs to help build the fundamentals.

Those fundamentals are typically concepts like variables, if statements, and outputting text. They are not things like adding fiery swords into games or building a social-media network. Nobody goes from writing their first program to coding World of Warcraft, and that's okay!

This is why I suggest focusing on exactly two things as you get started:

Are you learning?
Are you having fun?

If either answer is "no" for longer than a week, then you're probably going to lose focus (this post should help you find fun and effective ways to learn).

The coding landscape has changed a lot in the last 10 years or so. Coding bootcamps started popping up around 2011. They serve as a focused, immersive way of learning coding quickly, and even then, it takes 3-6 months of full-time (sometimes more than full-time) learning.

In addition, tools for programming have become much more accessible. I mentioned that you won't be adding a fiery sword to a game, but thanks to game engines and modding, you actually could add one without even writing a single line of code. However, that's sort of like saying that you can lift a car so long as you have access to a crane; the tool takes time to learn and use, but it's doing the heavy lifting for you.

Don't get me wrong—I don't say this to delegitimize game engines or the work that people do. Instead, I'm saying that if you want to learn programming, then at some point, you'll have to learn what goes into making those tools. By all means, start your programming journey with Minecraft mods or the Unity game engine.

This brings us to the last question that I get all the time:

Question: which programming language should I learn first?

Alternatively, I hear this as "is Language A better than Language B?"

This is the beauty of learning programming: it doesn't matter! Here's why:

You need to start somewhere.
You will likely learn many languages if you continue programming.
Technology changes rapidly enough where the popularity of languages will also change over time. This even leads to the death of some languages or environments (e.g. Flash), thus forcing you to move away from the specifics that you've learned.

In my opinion, the time you spend debating on which language to learn is time wasted. If you want someone to pick for you, then go with Python:

There are tons of Python resources out there, so you'll be able to find support online for any problems you run into.
It's still actively used in the professional world.
It can be set up in roughly a minute on any operating system.
It reads almost like English in some cases.

How to go about learning

In general, learning programming is no different from learning anything else. It's some combination of studying, practicing, and talking to other people (e.g. teachers and coders). Studying and practicing will help you internalize the skills and come up with questions to further your knowledge. Talking to others will prevent you from building bad habits.

More specifically, there are lots of resources out there. People ask me which ones I recommend, but unless it's a resource that I used in the last couple of years, it could be out-of-date and I wouldn't know! Instead, I suggest looking at something like this absolutely massive list of free programming books. Augment that with YouTube videos, general Internet searches, and the resources that your friends and teachers recommend, and you should be set.

At some point early on, you'll probably ask, "what project should I work on next?" It's crucial to pick the right project, because if you don't like it, you'll simply stop working on it. If that happens early enough into your programming endeavors, then you may stop learning altogether.

The sections below contain important notes on how to choose a project.

Scope

Always pick a project that is slightly beyond your current skill level. This concept is called scoping the project. An overzealous scope is the biggest killer that I've seen for personal projects. It's tempting to put in a couple of weeks of time learning the basics and then jump right into making that game or site that you've always wanted to build. It's much better to prune that idea down to just one or two systems.

For example, suppose you were interested in making your own version of Twitter. Here are some projects of various sizes that you could implement:

A "tweet typer" that counts your characters as you type and warns you when you've gone over the limit
A site where text blobs get downloaded from a server as you scroll down the page
A sign-in system
A mobile app that renders a website
A link-shortener service

I didn't spend a long time typing that list, and I didn't even cover 10% of what Twitter actually does.

If you find yourself on a project whose scope ends up being larger than you thought, then don't hesitate to cut features completely. Remember that your primary goals should be learning and having fun, so try not to add pressure to yourself by tackling a project that intimidates you.

Domain

Do you like games? Sites? Graphics? Networking? Algorithms? Utilities?

There are hundreds of domains from which to choose a project, and I can't answer for you what you'll find interesting or fun. Going back to the Twitter-clone example, suppose you didn't want to make a sign-in system, but you felt that it was too important to skip. The good news is that someone out there has already made the system for you! You can look into what they did and incorporate it into your project (although be careful about licensing; I'm not advocating for plagiarism or theft!).

If you didn't want to go that route, then just take a shortcut to where you feel like you'll learn and have fun. When I didn't want to code sign-in systems, I just made buttons that said "Adam1" and "Adam2". Clicking them would act like I'd signed in, but I didn't need to make name/password inputs or even send that information to a server.

Design

Programming and product design are filled with microdecisions:

How should the site look as you shrink the browser?
Will users understand what I'm trying to convey here?
Is this game more fun without this system?

You can't ever completely remove decision-making from the equation, but you can drastically cut it down by reinventing the wheel. For example, if you wanted to learn game programming by making your own game, you just made two tasks for yourself: designing a game and learning how to develop that game. If you instead recreate an existing game like Tetris or Pong, then you can focus solely on the code (obviously don't actually claim other people's work as your own or try to sell it).

I've done this before where I wanted to learn a new language or framework without having to come up with my own unique project, and it's so refreshing to bypass all of those decisions that would typically nag at me.

What to learn

I talked about how to learn by making use of all available resources and picking the right project, but here's what you should learn regardless of which language you start with.

Self-sufficiency

Programming has a lot to do with self-sufficiency. If you've ever fixed someone else's computer problem by Googling the issue, then you know how powerful this can be. A good programmer doesn't memorize everything; they just know how to solve problems as they arise. For new programmers, StackOverflow will be a great resource. You'll find anything from basic questions like "what does 'syntax error' mean?" to more advanced ones like "how do I integrate these two systems?"

I've written that you should use other people as resources, and now I mention that you should be self-sufficient. Which is it? Programming is full of "small" problems that can expand to fill your whole day, and you'll frequently find that you save yourself hours by just asking someone early on. In the end, it's a judgment call of when to involve other people. For quick, factual questions like "can I make a website with JavaScript?", I think you should almost exclusively be searching the Internet. For more involved programming problems like "why isn't my code working how I want it to?", you sometimes need to sink your teeth into the problem to understand your own thought processes before asking for help.

Debugging

Everybody writes bugs. We all strive to write them infrequently and to find and recover from them quickly. Experience will help you with the former, and debugging will help you with the latter.

Most modern languages have an easy way to debug them (e.g. PyCharm for Python, browsers for JavaScript). The two most significant aspects to learn are how to place breakpoints and how to inspect variables. With breakpoints, you'll be able to stop your program at a specific line of code, that way execution is frozen in time. Then, you can inspect variables to see if your assumptions hold true. I still find myself saying, "this can't be happening because I turned this flag on" only to debug and see that the flag is really off.

You haven't fixed a bug until you've fully understood it. The reason why this is so important is because when you come across a bug, you immediately make a bunch of assumptions. Suppose that the bug is a missing image on your site, and your initial hunch is "the image file doesn't exist." You look in the folder that should contain the image and you see it there. Then you think, "maybe one of my libraries got updated and that's having trouble rendering the image." You investigate that and make some changes, and in the process, the bug is solved, but you don't know why.

If you stop there, it's possible that the bug still exists but that you don't realize it. In this particular example, let's say that the bug was caused by trying to access the file on a Tuesday for some reason. You're clearly going to encounter this bug again, but you'll assume you dealt with it. That's why it's so important to understand the root cause of a bug.

Whenever you find [and eventually fix] a bug, you should ask yourself these questions:

Where else might this bug exist in my code?
How will I prevent myself from hitting this bug in the future?
What techniques/knowledge did I learn that could help me find any bug faster in the future? For example, maybe you learned that logging is helpful or that you tend to make typos in filenames.

Miscellaneous

Learn more interactively
- Take notes to reinforce concepts.
- Test out programs for yourself so that you're not just assuming how they work.
- Don't be afraid to look through code that you don't own. Open-source software is everywhere nowadays, so if you're using an open-source library and you have a problem, then dig in!
Recognize your accomplishments. Impostor Syndrome runs rampant amongst programmers. You will know more one week into programming than you did when you began, and you'll know much more after another month or year. It all happens so gradually that it's easy to focus on people more experienced than you and wonder why you're not there yet, but getting there only happens with time and effort.
Start NOW. You just read this blog post, so you were motivated enough to do that (and good job, by the way!). Carry that momentum over to python.org or any number of other sites and go write your first program! It's completely free and you'll open up a whole new world for yourself.

Why should you learn programming?

I'm putting this section at the end because you had your own reasons for even arriving at this blog, so this section is just to bolster those reasons:

Technology is everywhere. I went to the store before writing this blog post and saw a barbecue grill with Wi-Fi built-in. I can't believe I'm typing this sentence, but... some amount of programming had to be done to make that grill work. You never know what possibilities might arise in your own lifetime where programming may help.
It's full of problem-solving, which can be deeply satisfying. There's nothing quite like spending hours investigating a pesky bug only to find out its true cause and then share the results with your co-workers, customers, or annoyed significant other.
There's so much to explore! You'll go from "software is a mystery" to "how would I have implemented that?" sooner than you think. That opens up doors for you. You may write an application that your friends love, automate parts of your house, or just tinker around with something technical and fun. I combined several of my own interests by learning how to type with a piano keyboard. Who knows what you'll end up doing?