How to Learn Programming

This guide is a little different from most guides on learning to program in the mid-2020s. You'll find some concrete advice and steps to get started, but the emphasis is on how to think about the process rather than what specific tools to use. See Learning Python for more context-specific suggestions.

What Do You Mean By Programming?

In my experience there are at least five types of programming. They are certainly related, but "learning programming" usually means starting with one of them:

Programming contests or puzzles — Competitive programming, algorithmic challenges (LeetCode, Advent of Code)
Scientific or financial programming — Data analysis, modelling, simulation; heavy on mathematics
Programming applications — Back-end, mid-layer, native apps; the classic software engineering path
Graphics, front-end, and web programming — What things look like and how they behave in a browser
Low-level programming — Systems programming, embedded systems, hardware interfaces

Some areas require thinking from more than one of these. Games are a particularly good example — graphics-heavy games draw on both front-end thinking and performance-critical low-level thinking.

There are many opinions about what to learn first. I don't really have a strong "should" here: learn whatever gets you excited and interested so that you can continue. If you have a specific goal, diving directly into the area that serves that goal is often the smoothest path in.

A Coding Process for Bigger Challenges

When confronted with a programming challenge that appears large and unclear, there are a few rules of thumb that can do wonders for your confidence:

1. Write the problem in your own words.

Rewrite the assignment brief or problem description as if you were explaining it to someone else. This forces you to identify what you don't understand. If the brief is vague — "build a website for yourself," "create a map for a game" — start by writing out the smallest, simplest thing you can think of that might get the job done.

2. Think through what variables you'll need.

As you work through the problem, note what variables you'll need and what type they might be. If you're not sure of the data type, think through what you need the variable to do — what it needs to store, how it'll be manipulated. Then look at documentation about data structures that might solve that problem. Pick the simplest option to start with, even if it doesn't meet all your needs perfectly.

3. List the behaviours you want the program to produce.

Break each larger behaviour into as many substeps as you can. For example, "tell the user where they are located" might break down into: provide a prompt and a chance for them to ask; receive their input; process it; provide an answer based on a stored variable. If you haven't stored the variable yet, that goes at the top of your list.

4. Think through conditions and function signatures.

What if/else checks do you need? What does each function need as input, and what type should it return? It's fine to have if-statements and function definitions sitting in your editor with "TODO" comments marking what needs to happen before and after.

All of the above can be done in any text document, or on paper. Some people plan; others write a lot of comments in their code that cover the same ground. Either approach works.

When You Get to the Actual Coding

Start with the simplest editor you can. Especially at the beginning, a fully-fledged IDE can feel overwhelming. For my courses I recommend starting with online "lite" environments — Jupyter Notebooks, online C# interpreters, Replit. With that in mind:

Name things clearly. A good variable name is descriptive, even if it ends up longer than you'd like. Abbreviated names you can't recognise later are the worst kind.
Comment as you go. Describe your intentions for each section of code. This helps you solve problems before they happen and makes changes easier later.
Print statements are your friends. If you need to check the state of a variable before an if-statement or during a loop, print it with a short label. Digital ink is free.
Not knowing where to begin is normal. Starting is more important than being correct. Writing a plan (see above) helps you find your footing, and also makes it easier to ask for help effectively.

"I don't get it" is not a productive way to ask for help. "I am stuck on this part of the plan because I don't understand how to do X" points someone directly to where the gap is. This applies to teachers, colleagues, and documentation alike.
Everyone uses documentation. Not remembering how something works is expected. Not knowing how to find it isn't necessary. Learning to read documentation — understanding what methods and functions exist and how to use them — is what programming looks like at the beginning, middle, and end. The documentation and problems just get more complex over time.
Do the minimum required first, then expand. It's easy to get absorbed in the part of a project you find interesting and forget the rest. In coding, the minimum requirements are usually genuinely enough to demonstrate what you've learned. Anything beyond that is for your own learning, not for the assignment.

A Note on Getting Stuck

Getting stuck is not a sign that you can't do this. It is the normal state of writing software.

The useful question to ask when you're stuck is not "why can't I do this?" but "what specifically don't I understand right now?" Often this leads directly to what you need to look up, or what you need to ask.

If you've been stuck for a while and your usual approaches aren't working: step away, come back, and try to re-read your own code as if it were someone else's. The problem is usually closer to the top of the file than you think.