Count steps, not seconds

Lesson 1 · Big-O for the BUILD Camp room · one win: predict an algorithm's future without running it

A stopwatch tells you how fast code ran today, on this laptop, with this input. It tells you nothing about next month, when the input is a thousand times bigger. Big-O is the tool that answers the question the stopwatch can't: how does the cost grow as the input grows?

A courier's bad day

From the source lecture: a Ninja Xpress courier must visit several addresses and return to the warehouse by the shortest route. With 5 addresses there are 4! = 24 possible routes — you could check them all by hand. With 20 addresses there are 19! ≈ 1.22 × 10¹⁷ routes. Same problem, slightly bigger input, and suddenly no computer on Earth checks them all.

“But my code runs fine!” — It runs fine at today's n. The courier's route-checker also ran fine at n = 5. Growth, not current speed, is what kills systems.

Why not just measure seconds?

The lecture gives two reasons real time is the wrong yardstick (slide 16): different machines execute the same operation at different speeds, and different compilers generate different machine code. A measurement in seconds describes your hardware as much as your algorithm.

So instead we count steps: how many times the algorithm performs its typical operation (operasi khas), as a function of the input size n. That count is the time complexity T(n) — and it's the same on every machine.

Counting T(n) by hand

Averaging an array of n numbers (pseudocode from slide 22).

Listen first: the algorithm sets sum to zero, then loops i from one to n, adding the i-th array element into sum each time. After the loop it divides sum by n to get the average. The typical operation is the addition inside the loop, and the loop body runs exactly n times.

sum ← 0
for i ← 1 to n do
  sum ← sum + a[i]
endfor
average ← sum / n

The typical operation — adding an element into sum — runs exactly n times. So T(n) = n. That's the whole technique: pick the operation that characterizes the algorithm, count how many times it runs in terms of n.

Finding the largest element (pseudocode from slide 23).

Listen first: the algorithm starts by assuming the first element is the maximum, then loops i from two to n. Each pass compares the i-th element against the current maximum, and replaces the maximum if the element is bigger. The typical operation is the comparison, which happens once per loop pass — n minus one times.

max ← a[1]
for i ← 2 to n do
  if a[i] > max then
    max ← a[i]
  endif
endfor

Here the comparison runs n − 1 times, so T(n) = n − 1.

The simplification move

Is T(n) = n meaningfully different from T(n) = n − 1? For growth, no. When n is large, only the fastest-growing term matters, and its constant factor doesn't change the shape of the curve. So the rule (slide 31) is:

Keep only the term with the highest order.
Drop its constant coefficient.

Examples from the lecture: 6n² + 100n + 300 → n², 3n³ + 4n² + 300 → n³, and a constant like 5 → 1. What remains is the algorithm's asymptotic complexity — Big-O when we state it as an upper bound. (Next lesson sharpens the difference between Θ, O, and Ω.)

The ladder of growth

Because so much gets thrown away, only a few distinct growth functions survive in practice. Slowest-growing (best) to fastest-growing (worst), from slide 32:

Common asymptotic growth functions, slowest to fastest.
Growth	Name	Feels like
1	constant	same cost at any size
log n	logarithmic	doubling n adds one step
n	linear	cost scales with the data
n log n	linearithmic	good sorting lives here
n²	quadratic	nested loops over the data
2ⁿ	exponential	each extra item doubles the work
n!	factorial	the courier's 19! routes

Cold-recall defense (one breath):
Big-O describes how an algorithm's cost grows with input size, not how fast it runs today. To find it: count the typical operation as T(n), keep the fastest-growing term, drop its constant.

Check yourself

Quiz — answer before scrolling on. (In the live session: shout your answers; wrong answers pick the next lesson.)

Measuring an algorithm by wall-clock seconds is unreliable because…
A. slow algorithms can't be timed accurately
B. results depend on the machine and compiler
C. seconds can't be converted into steps
T(n) = 4n² + 20n + 500 simplifies to…
A. n²
B. 4n²
C. n³
The courier problem explodes from 24 routes to ~1.22 × 10¹⁷ because its growth is…
A. quadratic — n²
B. exponential — 2ⁿ
C. factorial — (n−1)!

Primary source

Kompleksitas Algoritma (Big-O) — Zain Fathoni's 2020 guest lecture at Politeknik Negeri Jember (local copy: assets/big-o-2020-jember-slides.pdf, ~15-min read, Indonesian). For the notation itself, Khan Academy's asymptotic notation series (~20 min) is the deck's own reference.

💬 I'm your teacher for this — ask me followups any time.

Lesson 1 · workspace big-o · mission: prove fundamentals can be learned faster with AI — BUILD Camp, 4 July 2026