Programming Fundamentals · Complexity: Is This Code Worth It?

Big-O: See at a Glance How Long Code Will Run

The sister part covered “data structure = how you store things.” This chapter covers the other half: algorithm = a playbook for getting work done. To judge whether a playbook is any good, programmers share one ruler: Big-O. Don't let the math symbols scare you—it answers only one question: when the data grows, how much slower does your code get? Today, three interactives will install that ruler in your head.

Interactive 1 · Four curves diverge

Time curves for four common “playbooks”: O(1) gray (one step no matter how much data), O(log n) green (cut in half each time), O(n) blue (walk through one by one), O(n²) red (everyone compared with everyone). Drag the slider from 10 to 100,000; the right side converts to real time at “100 million ops/sec.” Watch: early on, all four lines pile together—when data is small every algorithm looks fast, which is exactly why demos lie.

Data size n 100

Drag all the way left first, then slowly right. Below n = 100, all four lines hug the floor—that's “everything fine in the demo stage.” Past 10k, the red line takes off; at 100k, O(n²) already needs 100 seconds, while the green line is still near zero.

Interactive 2 · What if data grows 10×

A more direct question: your boss says “users will 10×”—how much slower does each playbook get? Hit “×10,” click three times and watch the gap snowball.

Current data size 1,000 items

Remember this pattern first: when data ×10, O(1) stays put, O(log n) only +a bit, O(n) also ×10, O(n²) jumps ×100. Click the button a few times to check.

Interactive 3 · Guess this code

You've got the ruler—time to try it. Three snippets of pseudocode; pick a complexity for each. Trick: don't read every line—just ask “when data grows, how much more work does it do?”

Why this ruler helps you? When you review AI-written code later, you don't need to understand every line—just ask: “What's the complexity here? Can it still run at 100,000 rows?” The AI will tell you straight. And most “got slower and slower after launch” incidents turn out to be one O(n²) hiding in a corner. Next lesson we look at the most famous O(n²) inside LLMs—the attention mechanism.

What this lesson wants to share

Big-O only tracks the trend: it doesn't care how fast one run is—only how time grows as data grows
Constants don't matter; trends kill: 2× slower is fine; growing with n² is a death sentence
Small data hides the gap: four curves pile together in the demo stage; the explosion waits until data grows
n² causes most lag accidents: when reviewing code, hunt nested loops first