It's About How Things GROW

Here's the thing nobody says out loud when they teach this: Big-O is not about how fast your code is. It doesn't measure seconds. It doesn't know what computer you're on. It can't tell you whether your program finishes in 2 milliseconds or 2 minutes.

What it does tell you is something more useful: as your input gets bigger, how does the amount of work grow? That distinction is the whole game. Once it clicks, the notation stops being scary, because the notation is just a shorthand for an answer you can reason out yourself.

The one question to keep asking

Whenever you look at a piece of code, ask:

If I double the size of the input, what happens to the work?

That's the question Big-O answers. There are only a few possible answers, and they're all things you already understand from real life:

• The work barely changes. Doubling the data makes almost no difference. (Looking up one word in a dictionary doesn't get harder when the dictionary gets thicker - you flip near where it should be.)
• The work doubles too. Twice the data, twice the work. Fair and predictable. (Reading every page of a book: twice as many pages, twice as long.)
• The work squares. Twice the data, four times the work. This is the one that quietly ruins your afternoon. (Everyone at a party shaking hands with everyone else: invite twice as many people and you get roughly four times as many handshakes.)

Big-O is just a tidy label for which of these is happening. O(n) means "doubles." O(n²) means "squares." O(1) means "barely changes." The letter n is the size of your input - the number of items, rows, users, whatever you're working over.

📝 Terminology. Input size is what n stands for: how much stuff your code has to chew through. 1,000 users? n is 1,000. The whole point of Big-O is to describe behavior as n gets large, because that's when the differences become impossible to ignore.

Why "exact speed" is the wrong thing to measure

You might wonder: why not just measure seconds? Because seconds depend on a hundred things that have nothing to do with your code - the machine, the language, what else is running, whether the data was warm in cache. Run the same code on a laptop and a server and you'll get different numbers.

Big-O throws all of that away on purpose. It ignores the machine and asks only about the shape of the growth. That's why a single Big-O label is true everywhere: an O(n²) algorithm has the squaring problem on your laptop, on a supercomputer, and on a phone. The hardware changes how long each unit of work takes; it does not change how the work grows.

💡 Key point. Big-O describes the shape of the curve, not a point on it. A faster computer slides you along the same curve. It does not give you a different curve.

Seeing the shapes

The reason growth matters so much is that the shapes pull apart violently as n gets big. At tiny sizes they all look about the same. Then they don't.

Here's the same handful of inputs run through the common growth shapes. The numbers are the amount of work, not seconds - counts of basic steps:

   input size (n) →        10        100         1,000        1,000,000
   ─────────────────────────────────────────────────────────────────────
   O(1)   constant          1          1             1                 1
   O(log n) logarithmic    ~3         ~7           ~10               ~20
   O(n)   linear           10        100         1,000         1,000,000
   O(n log n)              ~30       ~700       ~10,000      ~20,000,000
   O(n²)  quadratic       100     10,000     1,000,000   1,000,000,000,000

What just happened: Look across the bottom row. When n is 10, the quadratic algorithm does 100 steps - totally fine. When n hits a million, it does a trillion steps. Meanwhile the O(log n) row barely moved: from ~3 steps to ~20 across the entire range. Same inputs, wildly different fates. That gap is the entire reason anyone cares about Big-O.

And here's the shape of it as a rough picture - work going up the side, input going across the bottom:

   work
    ▲
    │                                              ╱   O(n²)  - shoots up, squares
    │                                          ╱
    │                                      ╱
    │                                  ╱
    │                            ╱  ╱        ___ O(n log n)
    │                      ╱  ╱        ___---
    │                ╱ ╱      ___---            ________ O(n)  - steady, straight
    │          ╱  ___---_______------
    │     ╱_---______------- ··········· O(log n) - almost flat
    │ _-=···························· O(1)  - flat line
    └──────────────────────────────────────────────────────────►  input (n)

What just happened: The two lines hugging the bottom (O(1) and O(log n)) barely rise no matter how far right you go - those are the shapes you want. The straight diagonal (O(n)) is plain and fine. The one curving sharply upward (O(n²)) is the one that looks harmless on the left and becomes a cliff on the right. Your job, most of the time, is just to not be on that top curve when n is big.

⚠️ The trap of small inputs. Everything looks fast when n is 10. That's exactly why bad scaling hides - your code sails through testing with a few rows and then falls over in production with a few million. Big-O is the tool that lets you see the cliff before you drive off it.

So what is Big-O, in one sentence?

Big-O is a label for how the work grows as the input grows - barely, linearly, or explosively - so you can predict whether code that's fine today will survive when the data gets big.

No limits. No proofs. Just: double the input, what happens to the work? Hold onto that question. Everything in the next phase is just five common answers to it.

Recap

1. Big-O measures how work grows with input size, not how many seconds something takes.
2. The one question: double the input - does the work barely change, double, or square?
3. n is the input size; Big-O describes behavior as n gets large.
4. The shapes look identical for tiny n and pull apart violently as n grows - which is why slow scaling hides during testing.
5. A faster machine moves you along the same curve; it doesn't give you a better one.

Next, the small set of shapes you'll actually run into - and how to name each one straight from the code.

Watch how a simple sort actually moves the data - each comparison and swap is one step of work that grows with n:

← Guide overview · Phase 2: The Few You Actually Meet →