LetItCrash

How to trace an expression, step by step

LLM-authored, human-reviewed

Foundations

The Trace Exercises on this site ask you to predict how a JavaScript expression evaluates, one step at a time, before running anything. No debugger. No console. Just you and the language rules.

This is the substitution model in action. You learn to see code as an expression that reduces, not as instructions that happen. Everything later on this path - the substitutions exercises, lambda calculus, reasoning about Elixir, the algorithm problems - assumes this skill. These exercises build it.

What a trace is

A trace writes the same expression again and again, reducing one part per line until only the value remains. It is the same idea as showing your work in arithmetic:

2 + 3 * 4
2 + 12
14

Each line after the first is the whole expression with exactly one part replaced by what it reduces to.

The one-reduction rule

Each line must be the whole expression, with exactly one part reduced.

  • One reduction per line: 2 + 3 * 4 → 2 + 12 → 14.
  • Never skip: 2 + 3 * 4 → 14 reduces two things at once, and the checker flags the skipped line.
  • Never write just the reduced part: the line 12 on its own is not a step - the whole expression stays on the page, changed in one place.

Which part reduces first

The evaluation order rules determine what changes on each line:

  1. Operator precedence - * and / bind tighter than + and -. In 2 + 3 * 4, the multiplication reduces first: 2 + 12, then 14.

  2. Function calls expand first - a call becomes its body with the argument substituted. With function square(x) { return x * x; }, the expression square(3) + 1 reduces like this: 

    square(3) + 1
3 * 3 + 1
9 + 1
10

  3. Then left to right - when two equally-precedenced parts are ready, the left one goes first.

The last line is the value alone - no expression left to reduce.

The checker is strict about order

The checker compares your trace with the expected reduction line by line, in order. It highlights the first difference in red. That line shows exactly where your mental model disagrees with the language rules - where the language behaves differently from your prediction.

Use that red line as the lesson. After a wrong trace, the nudge points there, not at the whole exercise.

Study first, then do

The first time you open an exercise, you may land on the study view: the whole reduction is shown, including the final value, with a prompt to explain it to yourself in your own words. Studying never counts as solved - you solve it at the harder level. When you can reproduce the reduction without looking, switch to the harder level and write the trace from scratch.

Common first mistakes

  • Reducing two parts in one line - one reduction per line, always.
  • Writing the reduced part alone instead of the whole expression.
  • Reducing in the wrong order - precedence first, then calls, then left to right.
  • Stopping before the final value - the trace ends when only a value remains.

Why this matters

Tracing is prediction practice. Every bug you will ever debug is a place where your mental model of what the code does disagrees with what it actually does. Tracing trains you to find that disagreement on purpose, cheaply, before the code runs. If you can trace, you can reason about code you have not executed yet. Every harder exercise on this site builds on that skill.

Where to go next

Related exercises

← Back to articles

Exercises