Reading code is a skill you learn separately from writing code — and it comes first. Before you can write a program, you need to be able to look at one and understand what it does, step by step, in the right order. This article explains what it means to read code, why it is harder than it looks, and how to get better at it.
This article is the starting point for the Code Reading, Tracing & Prediction section of the knowledge base. Other articles in this section go deeper on specific techniques — trace tables, PRIMM, loop tracing, and more. Start here.
Each section uses three depth levels. Read the Basic Idea first. Go deeper when you are ready.
| Level | What it covers | When to read it |
|---|---|---|
| Basic idea | What every programmer needs. Read this first. | Right now. |
| At a deeper level | The reasoning behind the basic idea. Helps you understand why this approach works. | Once you have tried reading a short program on your own. |
| At the deepest level | How this connects to bigger ideas in computer science. Not required for Grade 9. | When you are curious, or when the basic approach stops feeling like enough. |
1 What Does "Reading Code" Actually Mean?
Reading code means looking at a program and figuring out what it does — without running it. You are playing the role of the computer: working through each line in order, keeping track of what is stored in each variable, and predicting what will appear on screen.
This is different from reading English. In English, you can skip words and still understand the sentence. In code, every character matters. One wrong symbol changes what the program does. You have to slow down and be precise.
Here is a short program. Before reading on, try to figure out what it prints.
score = 45
bonus = 10
total = score + bonus
if total >= 50:
print("Pass")
else:
print("Not yet")The answer is Pass. Did you get it? If you did, you just read code. If you were not sure, that is exactly what this section of the knowledge base is here to help with.
When you read code, you are doing three things at once:
- Tracking values. Every variable has a value. That value can change. You need to know what each variable contains at each moment in the program.
- Following the order of execution. Python runs code top to bottom — but conditionals skip sections, and loops repeat sections. The order is not always as simple as "line 1, line 2, line 3."
- Predicting the output. Once you know what is stored where and in what order things run, you can predict exactly what the program will print, return, or do.
These three skills — tracking values, following execution order, predicting output — are the foundation of everything else in this section. All the techniques (trace tables, PRIMM, loop tracing) are just tools to help you do these three things more reliably.
You can read every word of a poem and still not know what it means. The same thing happens with code. Reading means you can follow the syntax. Understanding means you can explain why the programmer wrote it that way, what would happen if you changed something, and what the program would do with different inputs. Aim for understanding, not just reading.
Researchers who study how people learn to program call the ability to read and trace code notional machine understanding — you have a mental model of how the computer works that is accurate enough to predict what it will do. The notional machine is not a perfect model of real hardware; it is a simplified model that is correct enough to reason about programs.
Beginners often have a broken notional machine — they believe variables work one way when they actually work another, or they think loops repeat in a different pattern than they do. The exercises in this section are designed to surface those broken beliefs so you can correct them. A discrepancy between your prediction and the actual output is not a failure — it is information about where your mental model needs repair.
2 Why Reading Code Is Hard
Reading code is harder than it looks for two reasons:
- You have to hold a lot in your head at once. You need to remember what every variable contains while also reading forward to see what happens next. It is like trying to keep score in a card game while also playing the game.
- The computer does not do what you meant — it does what you wrote. Small differences matter enormously.
=and==look similar but do completely different things. A variable calledTotaland one calledtotalare two different variables. The computer is exact. Your brain tries to fill in gaps and make assumptions. That mismatch causes confusion.
The solution to both problems is the same: slow down, be deliberate, and write things down rather than trying to hold them in your head.
There are specific places where beginners almost always go wrong. Knowing where the traps are helps you watch for them.
| Common trap | What beginners think | What actually happens |
|---|---|---|
| Assignment vs. comparison | x = 5 and x == 5 do the same thing | x = 5 stores the value 5 into x. x == 5 asks a question: is x equal to 5? |
| Variable value at a given moment | A variable's value is whatever you last saw it set to | A variable's value is whatever the program last assigned to it — which may have changed inside a loop or conditional |
| When a loop stops | The loop runs until the variable "looks right" | The loop runs until its condition becomes False — which happens at a specific, predictable moment |
| What a function returns | A function that prints something also gives that value back | print() displays output but returns None. A function only gives a value back if it has a return statement. |
When you predict output and get it wrong, do not move on immediately. Stop. Figure out which of the traps above caught you. The moment you understand why your prediction was wrong is the moment your mental model gets more accurate. Getting it wrong and understanding why is worth more than getting it right by accident.
Cognitive scientists call the mental effort of holding multiple things in memory at once working memory load. Human working memory is limited — most people can hold around four to seven distinct things at once. A program with ten variables, a loop, and a conditional can easily exceed that limit, which is why reading code feels hard even for experienced programmers.
Techniques like trace tables (covered in a separate article) are not just organisational tricks — they are cognitive offloading tools. By writing variable values on paper, you move them out of working memory and into the world, freeing up mental space to think about what the program is doing next. This is the same reason that working mathematicians write down intermediate steps rather than doing everything in their heads.
3 A Process for Reading Any Program
Use this process every time you read an unfamiliar piece of code. It is not the only way, but it works for beginners and it builds good habits.
- Read the whole program once, top to bottom. Do not try to trace it yet. Just get a sense of what is there: how many variables, any loops, any conditionals, any functions.
- Find where execution starts. In a simple Python script, that is line 1. In a program with functions, look for the code that is not inside any function — that runs first.
- Trace line by line. Work through the program one line at a time. For each line, ask: what does this line do? Does it change a variable? Does it print something? Does it make a decision?
- Write down variable values. Do not try to hold them in your head. Use a piece of paper or the margin. Update values as they change.
- Predict the output before running. Once you have traced all the way through, write down exactly what you expect to see printed.
- Run the program and compare. If your prediction matched, your mental model is working. If it did not, find the exact line where your trace diverged from reality.
Step 6 — comparing prediction to output — is the most important step, and the one beginners most often skip. Running the program without predicting first is just watching the computer work. Predicting first forces you to commit to a model of what the program does. When your model is wrong, you know exactly what to investigate.
Here is the same process applied to a short example:
x = 3 y = x * 2 x = x + 1 print(x + y)
Working through it step by step:
| Line | What it does | x | y | Output |
|---|---|---|---|---|
x = 3 | Stores 3 in x | 3 | — | |
y = x * 2 | Stores 3 × 2 = 6 in y | 3 | 6 | |
x = x + 1 | Takes current x (3), adds 1, stores 4 back in x | 4 | 6 | |
print(x + y) | Prints 4 + 6 = 10 | 4 | 6 | 10 |
The output is 10. Notice that when y = x * 2 ran, x was still 3 — the change on the next line had not happened yet. This ordering catches beginners often.
Experienced programmers can read simple code quickly in their heads. You are not there yet, and trying to rush to that stage will give you a shaky mental model full of guesses. The slow, deliberate process above builds the accuracy that makes speed possible later. Speed is a product of practice. Accuracy is a product of method.
The process above is an informal version of what computer scientists call program execution semantics — a precise definition of what each line of a language does to the program's state. When you trace a program by hand, you are manually applying the execution semantics of Python, one rule at a time.
Professional tools for this exist: debuggers let you step through a running program one line at a time and inspect variable values at each step. Python's built-in debugger is called pdb; VS Code has a graphical debugger built in. These tools automate the trace process, but they are most useful when you already understand what a trace is — otherwise the output is just noise. Learn to trace by hand first. Then use the debugger to confirm.
4 What This Section of the Knowledge Base Covers
The Code Reading, Tracing & Prediction section contains several articles. Each one covers a specific technique or concept. This article is the introduction — the others go deeper.
| Article | What it covers | Start here when… |
|---|---|---|
| How to Read Code (this article) | What code reading is, why it matters, and a basic process to follow | You are new to reading programs |
| Trace Tables | How to track variable values line by line using a structured table | You want a reliable method for not losing track of values |
| Tracing Loops | How to trace while and for loops, and how to find off-by-one errors | Loops are confusing you |
| Tracing Conditionals | How to follow if/elif/else branches and predict which path the program takes | You are not sure which branch runs under which conditions |
| PRIMM: Predict, Run, Investigate, Modify, Make | A structured five-step method for learning from code examples | You want a full learning routine, not just a tracing technique |
| Predicting Program Output | Practice with worked examples at increasing difficulty | You want to test and build your prediction skills |
You do not need to read them in order, but most students find it helpful to read Trace Tables next, since every other technique uses trace tables in some form.
5 Why This Matters in This Course
In this course, you will often be asked to read code before you write it. This is deliberate. Reading a working program and understanding it is faster and less frustrating than staring at a blank file trying to invent everything from scratch.
You will also be asked to explain code live — in oral desk checks and project defenses. You cannot explain code you cannot read. The skills in this section are the foundation for those conversations.
Finally, code reading is how you check your own work. Running a program and seeing output is not the same as understanding why the output is what it is. If you can trace your own program and predict its output before running it, you are much more likely to catch bugs before they appear.
In this course, the first time you encounter most programming concepts you will see them in a working example before you are asked to write them yourself. This is the Predict–Run–Investigate part of the PRIMM approach used throughout the course. Reading comes before writing — not as a detour, but as the fastest path to writing well.
This also applies to AI-generated code. If you ask an AI assistant to help you and it produces code, you are responsible for understanding every line of that code before submitting it. The only way to meet that responsibility is to read the code — carefully, with the process above — and be able to explain what it does. Code you cannot read is code you do not own.
In Mode 1 (AI Off), you trace and predict on your own. In Mode 2, you can ask an AI to explain a piece of code — but you must then close the AI and write the explanation in your own words. In Mode 3, any code you submit must be code you can read and explain live. The mode changes. The responsibility to read and understand does not.
Research in programming education consistently finds that the ability to read and trace code is a stronger predictor of programming success than the ability to produce code from scratch. Students who can trace accurately can debug their own programs, understand error messages, learn from examples, and adapt code they did not write. Students who jump straight to writing without developing reading fluency tend to write programs they cannot explain and bugs they cannot find.
The deliberate practice sequence in this course — predict, then run, then investigate — reflects what the research shows: the gap between prediction and outcome is the most productive learning moment available in programming education. Every trace table you fill in and every wrong prediction you diagnose is training your notional machine. Over a semester, this practice compounds.
- In your own words, what does it mean to "read" code? How is it different from just looking at it?
- List the three things you are doing simultaneously when you trace a program.
Trace this program by hand and predict what it prints. Write down the value of each variable at each step, then check by running it.
a = 10 b = 3 a = a - b print(a * 2)
- Name two common traps that catch beginners when reading code. For each one, describe what the beginner thinks is happening and what is actually happening.
- Why is it important to predict the output before running a program, rather than just running it and reading what appears?
- Where in this course will the skill of reading code matter most? Give two specific examples.