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 my Twitch channel, 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.
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:
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:
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:
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.
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:
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.
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.
Programming and product design are filled with microdecisions:
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.
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.
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?"
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.
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:
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:
The biggest takeaway from all of this is that you should start learning! Don't create barriers for yourself by debating which language to choose.Check out my courses