How to learn coding

Learning to code feels huge because there seem to be endless languages and courses to choose from. In practice it comes down to a few habits: pick one language, set tiny goals, type real code, build small things and ask for help when you are stuck.

Pick one language and stay with it

There are hundreds of programming languages, and every one has fans telling you it is the one to learn. If you try to compare them all before you start, you may never start.

You don't need all of them, and the first one matters less than it looks. Variables, conditions, loops and functions work in much the same way across most languages. Once you understand a loop in one, a loop in the next is mostly new spelling. The hard part, learning to break a problem into steps a computer can follow, carries over completely.

So choose by what you want to make:

Python reads close to plain English and has very little punctuation to trip over, which makes it a gentle first language. JavaScript is the language browsers run, so if your goal is an interactive website, starting there means everything you learn shows up on a page you can click.

Then stay with your choice. Switching languages every few weeks feels like progress, but you keep relearning the basics and never reach the part where you build something. A fair rule: stay with your first language until you can build a small project in it without following a tutorial.

Set tiny goals

'Learn to code' is too big to act on, while 'print my name' is something you can do in the next five minutes. Small goals give you something you can finish today, and each finished one is proof that the next is possible.

A good first path has four steps, each built on the last.

First, print some words. This proves your setup works and that you can run a program:

print("Hello, Kitty")

Then use variables, names that hold values so you can reuse and change them:

name = "Kitty"
lives = 9
print(name, "has", lives, "lives")

Then make a loop, so the computer repeats work for you:

for day in range(1, 4):
    print("Day", day, "of practice")

That prints 'Day 1 of practice', then Day 2, then Day 3. range(1, 4) stops before it reaches 4, a common early surprise. Change the numbers and run it again to see.

Then build a tiny project that combines them. Here is a cat fact generator in eight lines:

import random
 
facts = [
    "A group of kittens is a kindle.",
    "Cats cannot taste sweet things.",
    "Cats spend much of the day asleep.",
]
print(random.choice(facts))

It uses a variable holding a list, a module from Python's standard library and a print. Nothing in it is advanced, but writing it yourself teaches you how the pieces fit together.

Type the code, don't just read it

Reading about coding is not the same as coding. When you read a tutorial, the code looks obvious because someone else has already made every decision. When you face an empty file, you have to make those decisions yourself, and that is the skill you are trying to learn.

So type every example instead of copying it, then change it. Swap the names or add a fourth fact. Each change asks a small 'what happens if...?' question, and running the code answers it.

Break things on purpose

Errors are how a program tells you what went wrong, so learn to read them early. Misspell print and run it:

pritn("Hello")

Python stops and ends its error with a line like this:

NameError: name 'pritn' is not defined

The last line names the problem, and the lines above it say which file and line it came from. Try breaking things deliberately: delete a closing quote, remove the indentation from a loop body, divide by zero. Seeing each error once, on purpose, makes it far less scary when it turns up by accident. Coding is learned one bug at a time, and the loop is always the same: type, break, fix, repeat. If you want to go further with errors, our error handling video covers what to do with them in real programs.

Build small projects

A small project teaches more than a stack of tutorials, because nobody has made the decisions for you. You choose how to store the data, and when you hit a problem no tutorial covered, you have to work out the fix yourself.

Good first projects are small enough to finish in an evening or a weekend:

• A calculator that asks for two numbers and an operation, then prints the answer.
• A to-do list where you can add, list and remove tasks.
• A cat fact generator like the one above, or a random quote, joke or name picker.

Start with the smallest version that works, then grow it. A to-do list might begin as a list in memory that forgets everything when the program closes. Version two saves the tasks to a text file. Version three lets you mark a task as done. Each step teaches one new idea (files, then changing stored data) without asking you to learn everything at once.

Avoid starting with 'my own social network' or 'a game like the one I play'. Big projects tend to stall halfway, and it is easy to give up on one that has. You will get there by finishing lots of small ones first.

Ask for help when you're stuck

Everyone gets stuck, including people who have coded for years. Experienced developers have learned when to stop struggling alone.

Start by pasting the last line of your error into a search engine: someone has almost always hit it before. If that doesn't help, ask in a forum, a community for your language, or on Stack Overflow.

A question that gets good answers includes:

1. What you are trying to do.
2. The smallest piece of code that shows the problem.
3. The full error message, copied as text.
4. What you expected, and what happened instead.
5. What you have already tried.

Writing it out often solves the problem before you post it, because explaining the code step by step makes you read what it really does rather than what you meant it to do.

Give yourself a time limit for being stuck. Struggling for a while is how you learn; struggling for a whole evening on one missing bracket is not.

Stop comparing yourself to senior developers

It is easy to watch an experienced developer write code quickly and decide you are not cut out for it. That comparison is unfair to you. They have spent years making the same mistakes you are making now, and their speed comes from having seen most errors before.

Comparing yourself to them mostly creates doubt, and doubt makes it easier to quit. Compare yourself with where you were last month instead. If you can now write a loop you couldn't write then, you are learning. If you would like more on keeping a healthy pace, our burnout video covers the signs to watch for.

Practise a little every day

Short, regular practice beats occasional marathons. A short session most days keeps what you learned yesterday fresh, so each one builds on the last instead of starting with a refresher. A long weekend session followed by two weeks off mostly means relearning.

Make the daily habit small enough that you will do it on a bad day, such as fixing one bug or rewriting one example from memory.

Common mistakes

• Language hopping: switching before you have built anything resets your progress each time.
• Tutorial loops: watching course after course without building anything of your own feels productive, but leaves you stuck at an empty file.
• Projects that are too big: start with something you can finish, then grow it.
• Copying code you don't understand: if you paste in a fix, work out why it works before moving on.
• Staying stuck in silence: asking a clear question is a skill, not a weakness.

Key takeaways

• Pick one language, Python for simple and friendly or JavaScript for the web, and stay with it.
• Set tiny goals: print, then variables, then loops, then a tiny project.
• Type, break, fix and repeat: reading about code is not coding.
• Small, finished projects teach more than watching tutorials.
• Ask for help, compare yourself only with your past self, and keep going.