Education · 6 min read

Read Code Like a Detective, as a Student

Students write code all day but rarely practise reading it. Learn the detective method — predict, run, explain — on one small Python mystery in your browser.

Published 2026-11-08

TL;DR

Reading code is most of a developer’s real work, and it is a skill you can practise like any other. Predict what a small program will print, run it, explain any surprise — and save the trace as a snippet. Ten minutes a day of reading makes everything you write better.

Key takeaways

Reading code is most of a working developer’s day — fixing a bug in a file you did not write, reviewing a teammate’s change, working out how a library behaves — so reading is the skill that makes your writing better, not a distraction from it.
The detective method is three steps: predict what the code will print before you run it, run it, then explain any difference. The prediction is the whole point — it forces you to commit to an understanding instead of nodding along.
One character can change the answer: in the mystery program, a strict greater-than means the first top scorer wins a tie, while greater-than-or-equal hands the win to the last one — careful reading is how you catch that before it becomes a bug.
Ask four questions of any code you read: what does it take in and give back, what changes as it runs, what happens at the edges like empty input and ties, and what would break if you changed one line.
Free gives you 20 code executions a day, 10 AI requests a day, 10 saved snippets, 3 private snippets, and 3 collaborators per snippet — upgrade to Pro ($9/month or $69/year) when your collection of reading notes genuinely outgrows 10 saved snippets.

Most of a Developer’s Day Is Reading, Not Writing

Students measure progress by the code they write: lines typed, programs finished, assignments submitted. But most of a working developer’s day is spent reading code somebody else wrote — fixing a bug in a file they did not write, reviewing a teammate’s change before it ships, or working out how a library behaves. Writing is the visible part of the job. Reading is the larger part, and it is the skill that makes the writing better.

That is good news for a student: reading is cheaper to practise than writing. You need one small function and ten minutes — no project idea, no blank file, no plan. And reading has a built-in check writing lacks: predict what the code will do, run it, and see if you were right. When you are wrong, you have found what you did not know yet.

The Detective Method: Predict, Run, Explain

Reading code like a detective means treating every program as a small mystery you commit to an answer for before you look. The method has three steps, and skipping the first one ruins it. First, read the code and predict what it will print — write it down before you touch the run button. Second, run it. Third, explain any difference between your prediction and the real output in one sentence.

The prediction is the whole point. Without it, reading is just nodding along: the code looks reasonable, the output looks reasonable, and you walk away believing you understood something you only recognised. A written prediction turns a vague feeling into a testable claim, and a wrong one points at the line where your mental model disagreed with reality.

One Small Mystery to Solve

Here is your first case: a short program that finds the top scorer in a class. Read it, write down what you think it prints, and only then run it. Paste it into the browser editor — Python is one of the 34+ executable languages on CoderFile (120+ syntax-highlighted) — and check your prediction.

# mystery.py — predict the output before you run it
scores = {"Asha": 88, "Ben": 92, "Cara": 92, "Dev": 79} def top_scorer(results): best_name = None best_score = -1 for name, score in results.items(): if score > best_score: best_score = score best_name = name return best_name print(top_scorer(scores)) # Expected: Ben

If you predicted Ben, you were reading carefully. Walk the loop like a detective walking a timeline: Asha’s 88 beats the starting value of -1; Ben’s 92 beats 88; Cara’s 92 is not greater than 92, so nothing changes; Dev’s 79 changes nothing. The answer is Ben, and the tie is the clue: the first top scorer wins, because the code only replaces the best on a strictly higher score.

Now change one character and re-run it: replace the greater-than with greater-than-or-equal-to. Cara wins now, because her 92 equals the best and equal is suddenly good enough. One character, a different winner, and no error message to warn you — the program runs perfectly either way. That is why reading matters more than running: the run button can only tell you the program works, never whether it does what you meant. Only reading the comparison tells you which scorer wins.

Four Questions to Ask Any Code You Read

The detective method works on any function if you ask the same four questions every time. First: what does it take in, and what does it give back? Our mystery takes a dictionary of names and scores and gives back one name — that alone tells you most of what it is for. Second: what changes as it runs? Two variables move through the loop — best_name and best_score — and everything else is fixed. Watching only what changes keeps a long function small in your head.

Third: what happens at the edges? If the dictionary is empty, the loop never runs and the function returns None. If every score is negative, the starting value of -1 still wins and the function returns None even though there are students. If two students tie — you already know. Edge cases are where programs quietly do something nobody intended — the first place a careful reader looks. Fourth: what would break if I changed one line? You answered that with the greater-than-or-equal-to test — every change you can predict is proof you understand the code.

Where to Find Code Worth Reading

You do not need to hunt for reading material; you already have three sources. The best one is your own code from a month ago: you have forgotten how it works, which makes you the perfect stranger to read it — if you cannot follow it now, nobody else could either. The second is your classmates’ public snippets: read one, predict its output, and compare notes with the writer. The third is the small functions inside Lab lessons — short, runnable, and attached to a lesson that explains what each one is for, so you can check your reading against the answer.

Keep the pieces small, under twenty lines, and read the same function twice: once for what it does, once for how it does it. The first pass answers “what comes out”; the second answers “why this line and not another”. A function you can explain both ways is one you own — and one you can defend in an interview without bluffing.

Ten Minutes a Day Builds the Habit

Make it a daily habit, not a weekend project. One function a day: predict, run, explain, and save the trace as a snippet — your prediction, the real output, and one sentence explaining any surprise. Ten minutes is enough: a habit kept for a month beats a heroic afternoon never repeated. After thirty days you will have thirty reading notes — worth more than thirty tutorials, because each one records a moment your understanding changed.

Share the habit, too. Swap one mystery a week with a classmate: each picks a function, hides the output, and challenges the other to predict it. The writer learns from the wrong guesses — each one shows them a line that reads differently from how they thought it did. That is pair reading, the cheapest feedback loop in programming.

When Your Reading Notes Outgrow Free, That Is the Upgrade Moment

Stay on Free ($0: 20 executions a day, 10 AI requests a day, 10 saved snippets, 3 private snippets, 3 collaborators per snippet) while it fits — one mystery a day fits easily. But reading notes accumulate, and deleting the trace of a surprise you learned from loses the record of how you changed. That is when Pro earns its $9/month or $69/year — unlimited saved snippets and executions, 100 AI requests a day, 10 collaborators per snippet, and unlimited private snippets — and Team ($19/user/month, or $15/user/month billed annually) covers a class reading code together. See the pricing page for current terms, and upgrade for a limit you hit, not for a feature you might use.

Your next step is small. Open the editor, paste in the mystery program, and write down your prediction before you run it. Then change the greater-than to greater-than-or-equal-to and predict again. Save both as snippets, each with your prediction and the one sentence that explains the tie — and tomorrow, read a function you wrote last month the same way. Ten minutes, one prediction, one surprise: that is the whole habit.

Frequently asked questions

I can’t read code I didn’t write. Where do I even start?

Start with the return value and work backwards. Find what the function gives back, then ask what has to be true for it to give that back. Ignore the middle on the first pass and read only the inputs, the loop, and the return — then trace one concrete example through it line by line, writing down each variable’s value as it changes. Small functions under twenty lines are the right training ground; a whole project file is not. After a few weeks of one function a day, code that used to look like a wall starts to look like a list of small decisions.

Should I use AI to explain code I don’t understand?

Yes — after you have tried first. Predict the output, run the code, and only then ask the AI assistant to explain the one line or block where your prediction was wrong. That order matters: the AI fills a gap you have already found, so you actually learn from the answer. Pasting a whole file into AI and nodding at the explanation teaches almost nothing, because you never discovered what you did not know. A good test is to ask the AI to quiz you on the code afterwards — if you can answer without looking, the reading worked.

What if my prediction is wrong?

Then the exercise worked. A wrong prediction is not a failure; it is the exact shape of something you did not understand, and the gap between what you expected and what the program printed tells you where to look. Write the gap down in one sentence — “I thought the second 92 would replace the first, but a strict greater-than keeps the first” — and save it with the code. Students who only ever run code they already understand never find their gaps, because nothing ever surprises them. Surprise is the signal.

How much of this can I do on the free plan?

Free ($0) gives you 20 code executions per day, 10 AI assistant requests per day, 10 saved snippets, 3 private snippets, and up to 3 collaborators per snippet — plenty for one mystery function a day, running it as often as you like, and saving each trace as a snippet with your prediction and the real output. Pro ($9/month or $69/year) adds unlimited saved snippets and executions, 100 AI requests a day, 10 collaborators per snippet, and unlimited private snippets, and Team ($19/user/month, or $15/user/month billed annually) covers a class reading code together.