Measuring Algorithm Growth with Big-O Notation

Hey, I'm Byte — and I want you to think about something: if you have a list of 10 names, finding one by checking each one takes 10 steps. If the list grows to a million names, the same approach takes a million steps. Double the input, double the work. That relationship is what Big-O notation captures. Big-O is a mathematical shorthand for asking: "As the input size n gets very large, how does the number of steps grow?" We write it as O(something). The key insight is that we care about the *shape* of the growth, not the exact count. Here are the most important classes: • O(1) — Constant time. Looking up an array element by index: arr[500]. No matter how big the array, it is always one step. • O(n) — Linear time. Scanning every element once, like finding the max in an unsorted list. Double n, double the work. • O(n²) — Quadratic time. A nested loop that compares every pair, like bubble sort. Double n, and the work quadruples. • O(log n) — Logarithmic time. Binary search: each step cuts the remaining problem in half, so a list of a million takes only about 20 steps. Why do we drop constants? Suppose algorithm A takes exactly 3n steps and algorithm B takes 50n steps. Both are O(n). For very large n, both grow at the same *rate* — a straight line. The constant 3 or 50 depends on your hardware, your language, your compiler — things outside the algorithm itself. Big-O strips those away so we can compare the pure mathematical structure. A quick rule of thumb: if you see one loop over n items, think O(n). Two nested loops over the same n items, think O(n²). No loops touching n at all, think O(1). An algorithm that halves its search space each step, think O(log n). These patterns are your starting vocabulary. (Code examples throughout use Python-style pseudocode — the logic applies in any language.)