This might seem pretty redundant considering the whole point of this website is to teach you how to code. But there’s a really important lesson (maybe even the most important lesson) that’s missing from the rest of the site. That lesson is this: programming isn’t really about the code.
Writing code is a big part of programming. But more important than the code is the process of figuring out what code to use in the first place. It doesn’t really matter if you’ve memorized the syntax of
for loops and
if statements if you don’t know when to use them.
Programming isn’t simply 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!
So if you’re flying through the tutorials and not really taking the time to write any code by yourself, you’re missing out on the most important lesson. The process isn’t really something that other people can teach you; you have to go through it yourself. That can feel pretty painful at first, but don’t worry- that’s normal!
It’s also normal to feel like you don’t even have any idea how to start. You’re not alone! Hopefully this guide will walk you through the process of programming.
The first step to programming is knowing what it is you want to program. But this isn’t always as straightforward as you might think.
If you aren’t sure where to start, check out the homework assignments at the bottom of every tutorial, or the tweak ideas at the bottom of every example.
But even if you’re given a homework assignment (like creating a Pong game, or making a website that shows pictures of your cat, or building a robot that drives in circles), it can be hard to know exactly how to start.
Try writing down the goal, in your own words (not code or pseudocode). Even if you’re given a homework assignment, rewriting it in your own words can help illuminate exactly what you’re confused about.
This is the single most important skill in programming.
Now that you have a goal, the first thing you need to do is break that goal down into smaller sub-problems. Smaller than that. Each step should be smaller than you think is interesting. Now repeat that process and split up your sub-problems into sub-sub-problems. When doing this, keep in mind the peanut butter and jelly sandwich challenge. Stay with me…
This is a common exercise done in science, technical writing, and programming courses. You have to write instructions for making a peanut butter and jelly sandwich. Your instructions might look like this:
But the twist is, the person following the directions (usually the teacher or another student) pretends to have no idea how to make a peanut butter and jelly sandwich. This challenge is sometimes worded as: could you explain how to make a pb&j sandwich to an alien?
The person (or alien) following the directions might use their hands to spread the peanut butter (you never told me to use a knife), or they might not open the jars (you never told me to open them), or they might put the pieces of bread together with the peanut butter and jelly facing outwards (you never told me to put them together a certain way).
Even if you fix those problems, you can usually always find parts of the instructions that are unclear or could be split up into smaller steps. You told me to use a knife, but you never told me which end of the knife to hold, so now my hand is bleeding. You told me to open the jars, but you didn’t tell me how, so I smashed them on the ground. You told me to put the pieces of bread together, but you didn’t tell me how hard I should press, so now my sandwich is a flat smooshy mess.
This isn’t a pb&j sandwich! (art by Eeve Somepx!)
The point of the exercise is to show you that stuff you assume is obvious isn’t always obvious to everybody else. In fact, you probably don’t even know which assumptions you’re making! Identifying your assumptions and clearly explaining stuff you just automatically do is much more difficult than it first seems.
That might sound silly, but this is exactly how computers are. They only do exactly what you tell them, so the instructions you give them have to be as detailed as possible. As detailed as the instructions you would give an alien.
Much better! (art by Eeve Somepx!)
If you’re having trouble breaking your problem down into smaller steps, another thing I try to do is: forget the computer for a second.
That might sound ridiculous since we’re talking about programming, but one thing that makes it hard to split a problem up into smaller steps is that we do a lot of those steps in our heads, and we expect the computer to do the same thing. The problem is, the code you’re writing is the computer’s head! So if you want the computer to do something in its head, you have to tell it how!
For example, if you’re creating a program that draws a garden, think about how you would draw it with a regular piece of paper and a pencil. How exactly do you decide where to put the pencil? Your answer is probably “I dunno, I just put it where I want to draw a flower, and then I draw a flower” - but try to take that apart. How do you know where to draw a flower? How do you draw a flower once you’ve decided where to put it?
Here’s how I like to think about it: pretend you have a dumb friend. Your friend is really dumb. They don’t know anything, especially about whatever your goal is. You have to write out instructions (in English, not in code) that your dumb friend could follow, knowing nothing about your goal, and have them accomplish that goal.
For example, if your goal is to draw a garden, you can’t tell your dumb friend just to draw a garden scene. They don’t even know what a garden is! So you break that down into smaller steps: draw the sky, some grass, and some flowers. But your dumb friend doesn’t know what the sky looks like, or what grass is, or how to draw flowers. So you have to break it down even further: draw a blue rectangle for the sky, then draw green lines for the grass (maybe break that down further and specify where and how many lines should be drawn), then some circles for flowers (again, break that down further and say how many circles and where).
Defining what you need to do step-by-step is the definition of an algorithm, you can use that to start writing code. For example, maybe now you have a smaller goal of drawing a blue rectangle, which is something you can look up in the reference or search for on Google.
Now that you’ve broken your problem down into smaller problems, you can start taking those problems on. But make sure you take them on one at a time!
What is the absolute smallest next thing you know you need to do? Do that first, without worrying about anything else. This step is usually pretty boring! If you don’t even know how to start, then your first step is getting a window with the right size. No you’ve got some code, which is a huge first step. What’s the absolute smallest next thing you know you need to do now? Maybe it’s adding a background color to that window. Then maybe it’s adding a simple shape- I usually start with a circle. Keep repeating that process.
Keep asking yourself that question: what’s the absolute smallest next thing I know I need to do?
If you’ve been reading the tutorials on this site, you probably know by now that your best friend is the reference of whatever language or library you’re using. That should be your first stop. If something isn’t working how you expect, then read the reference for every function on that line.
If it still doesn’t make sense, then Google is your second best friend. A lot of programming is actually reading. Reading the documentation, reading tutorials, reading posts made by other people with similar problems.
And since you’re working on one small step, your research should be pretty specific. You shouldn’t be googling things like “how do I draw a garden scene” - you should be googling more specific things like “how to draw a line in Processing”.
As you program, make sure that the small step you’re working on on actually works before moving on to the next step. You get the window size right, then you make sure the background color is right, then you start adding shapes. If you’re adding grass, you probably make sure that a single blade of grass works before trying to fill the screen.
What you don’t want to do is write a bunch of code that does ten different things, then try to run your program. It will never work, and you’ll have no idea where the problem is in your code.
Honestly, I try to run my program after every line I write. This allows me to see exactly what the line does, and immediately fix bugs as soon as they happen. If you don’t do this, you’re going to give yourself a ton of headaches.
You should also work on each step by itself before trying to combine it with other steps.
For example, if you’ve broken down your garden scene into smaller steps like drawing a sky, drawing grass, and drawing flowers, start by creating a program that only draws the sky. Separately from that program, create a different program that only draws the grass. Get each of them working by themselves before you think about combining them into your real project.
Let’s say you want to add a bird that moves around your garden scene. First, break that down into smaller steps: drawing a bird (which should be further broken down into drawing individual shapes), and moving something around your scene. Create one program that draws a non-moving bird, and create a separate program that draws a simpler shape that moves around in the pattern you want. Get those working separately, then combine them to show a bird moving around. Then get that working, and add it to your garden scene.
That might seem like a lot of work, but it will seriously save you a ton of time and headaches if you code this way. It’ll also make it a lot easier to get help on the Happy Coding forum and Stack Overflow.
It’s hard to help with general “how do I do this” type questions. It’s much easier to help with specific “I tried X, expected Y, but got Z instead” type questions. It’s also hard to help with general “this isn’t working and I don’t know why” type questions, especially when the code contains a bunch of extra stuff that’s unrelated to the actual problem.
Let’s say you’re having trouble getting the bird moving in the pattern you want. If you’ve worked in isolation, then you have a simple standalone program that just shows a circle moving in a pattern. Now you can ask a question like: I tried changing these variables to move the circle in this pattern, but it’s moving in this pattern instead. What’s going on?
That’s a much easier question to help with than if you posted your entire program, full of code that draws grass and flowers, which is unrelated to your actual problem. If you do that, you might be asked to post a Minimal, Complete, and Verifiable example or a Short, Self Contained, Correct (Compilable), Example.
And if you’re thinking about asking a question that says “How do I do XYZ?” then I’ll point you back up to the top: start by breaking your problem down into smaller pieces!
Hopefully that outlines the process of programming. Notice that writing code is only one small part of that process. The hard part is breaking down a problem into smaller steps and taking on those steps one at a time. That’s something you can only learn by doing it yourself!
So if you’re running through the tutorials and not really doing any homework, you aren’t going to get much out of this site. The real point of the site is to encourage you to work through the above process over and over again. That’s the only way to become a programmer!
That also means that if you do a lot of copy-pasting of code you find on the internet, you’re also short-cutting the above process. Checking out the reference and Google is a huge part of programming, but if you just take code without really understanding it and plop it into your project, you’re only going to give yourself a ton of headaches. You can’t get better at cooking if you only buy pre-cooked food! (I don’t know anything about cooking so I’m not sure if that metaphor holds up, but you get the point!)
If you do work through the above process, then you’ll have much better luck actually accomplishing your goals. But if you’ve done all of the above and you’re stuck on a particular step, then please post your question in the forum and I’ll be happy to help!