Algorithms & Complexity
Cost is behavior made visible
What this chapter is
This chapter is not a catalog of algorithms. It is not a race for cleverness. It is not about trick solutions.
This chapter explains why cost exists and how it shapes systems.
Algorithms are not about speed. They are about tradeoffs you cannot escape.
The core truth
Every operation has a cost.
If you do not name the cost, the system will pay it somewhere else.
Time, space, and complexity do not disappear. They only move.
What an algorithm really is
An algorithm is not code.
It is a decision procedure:
- how work progresses
- how often it repeats
- how it grows with input
Code is just the expression.
🧠 Mental Model An algorithm describes how effort scales, not what happens once.
Complexity is about growth, not size
Many misunderstand complexity as "fast vs slow."
That is shallow.
Complexity answers a deeper question:
What happens when this grows?
- More users
- More data
- More interactions
- More time
A solution that works at small scale can collapse silently at larger scale.
⚠️ Common Drift Systems fail when growth was never modeled.
Big-O is a warning label, not a badge
Big-O notation is often misused as a flex.
That misses the point.
Big-O exists to say:
- "This will get expensive."
- "This will stay stable."
- "This will surprise you later."
🧠 Perspective Big-O does not measure speed. It measures risk under growth.
The invisible loop problem
Most performance issues come from unseen repetition.
- loops inside loops
- repeated lookups
- redundant transformations
- recomputation instead of reuse
Individually harmless. Collectively destructive.
🧠 Architect's Note If work repeats, ask why before asking how fast.
Structure determines algorithmic cost
Algorithms do not live alone.
They sit on top of:
- data structures
- access patterns
- assumptions about ordering and uniqueness
A poor structure forces expensive algorithms. A good structure simplifies them.
This is why Chapter 2 comes first.
Space is a decision, not waste
Many developers fear memory usage unnecessarily.
Space can be used to:
- reduce recomputation
- preserve results
- stabilize performance
Caching is not optimization. It is time traded for space.
🧠 Mental Model Every cache is a promise about consistency.
Break that promise, and bugs follow.
When "fast enough" is correct
Not every system needs to be optimal.
Some systems need to be:
- readable
- stable
- predictable
- easy to reason about
Optimization too early creates:
- brittle code
- unclear intent
- defensive logic
🧠 Perspective The best algorithm is often the one that stays obvious longest.
When optimization is unavoidable
Optimization becomes necessary when:
- growth is real
- cost is measured
- failure is visible
At that point:
- remove repeated work
- move work earlier or later
- change the structure
- change the boundary
Micro-optimizations rarely matter. Structural changes do.
Minimal practice (still no code)
Problem: "You need to check whether a user already exists, and this check happens for every request."
Ask:
- How often does this run?
- What does it scale with?
- Is the cost constant or growing?
- Can structure remove repetition?
If the answer is "we'll see later," later will be painful.
What beginners gain here
- Relief from guessing
- A sense of scale
- Understanding why some solutions "feel wrong"
What experienced developers recognize
- Why systems slow down mysteriously
- Why fixes don't stick
- Why performance work feels endless
The cost was never named.
What this chapter deliberately avoids
- Algorithm lists
- Competitive programming tricks
- Language-specific optimizations
- Premature benchmarks
Those belong elsewhere.
Closing
Algorithms are not about cleverness.
They are about honesty.
Honesty about:
- growth
- repetition
- limits
- tradeoffs
When cost is visible:
- decisions improve
- systems stabilize
- surprises disappear
Hide cost, and it will surface at the worst time.