Weekly Video Notes — Classic of the Week. A foundational talk worth re-watching, paired with key frames and a short essay on why it still matters.

Fifteen years after it was delivered, Rich Hickey’s “Simple Made Easy” remains the single best talk on software complexity ever recorded. The thesis is one sentence — simple and easy are different things, and conflating them is the root cause of most accidental complexity. The argument is forty-five minutes of careful etymology, vivid analogies, and a vocabulary that has quietly entered the industry’s bloodstream (“complecting,” anyone?).

Simple ≠ Easy

Simple has one fold, one role; Easy is near at hand and familiar

Hickey opens with the etymology. Simple comes from sim-plex — one fold, one role, one task, one objective. It’s an objective property of a thing. Easy comes from the Latin adjacens — near at hand, familiar, within our existing skillset. It’s a relative property — easy for whom?

The two often diverge. Git is simple but not easy. A monolithic framework that lets you build a CRUD app in five minutes is easy but not simple. Most of the technologies we reach for because they’re easy quietly impose complexity on the systems we build with them.

Complecting — the verb that named the disease

Complecting — the act of braiding together what should be separate

The talk’s most influential coinage is complect (from complecti, to braid together). To complect is to interleave concerns that should be independent — state with identity, time with value, what with how, policy with mechanism. Once braided, they can never be reasoned about independently again.

“Simplicity is a choice. You have to think about what you’re doing.”

The architectural failure modes Hickey calls out have only become more relevant: ORM tools that complect domain model with persistence, frameworks that complect routing with business logic, agents and harnesses that complect prompt with policy with tool selection.

State and the cost of complexity

State as a primary source of complexity

A long middle section is Hickey building the case that state (mutable, place-oriented) is the root cause of most production complexity. He contrasts it with value (immutable, identity-preserving) — the central thesis that motivated Clojure’s design. Whether or not you write Clojure, the lens generalizes: every distributed system, every concurrent code path, every debugger session is harder in proportion to how much state is complected into it.

The toolbox: choose simple constructs

A vocabulary of simple constructs vs. their complecting counterparts

The talk closes with a side-by-side vocabulary — pick the simple construct on the left over its complecting counterpart on the right:

Simple Complecting
values state
functions methods (objects)
namespaces classes
data structures objects
polymorphism à la carte inheritance, switch/matching
set functions structural cycles
queues conventional inter-thread comms
declarative data manipulation imperative loops, fold

This isn’t a Clojure pitch — it’s a design discipline. Any language can be used to write simple programs; most languages make it easier to write easy ones instead.

Why this talk still matters in 2026

The frontier has moved on — from Hickey’s world of OO monoliths and threaded servers to ours of LLM agents and distributed inference. The content of the complexity has changed. The shape hasn’t. Every modern agent framework is a candidate to be re-examined through the simple/easy lens:

  • Does it complect tool selection with prompt with state?
  • Does it offer simple constructs, or merely easy APIs?
  • Is the easy onboarding deferring a complexity bill that will come due in production?

The discipline of asking these questions — habitually, ruthlessly — is what this talk teaches. It’s why “Simple Made Easy” is still the talk most often recommended to junior engineers, and still the talk most often re-watched by senior ones.

Key takeaways

  1. Simple = one fold, one role. It’s objective. Test it: can you reason about each thing independently?
  2. Easy = near at hand, familiar. It’s relative. Test it: easy for whom, after what?
  3. Complecting is the verb to fear. Braiding concerns destroys reasonability.
  4. State is the largest source of accidental complexity. Prefer values, identity, and time as separable concerns.
  5. There’s a vocabulary of simple constructs — values, functions, namespaces, data, queues, set functions. Reach for them by default.
  6. Simplicity is a choice that requires thinking. It’s never the path of least resistance.
  7. Re-watch this talk every couple of years. The complexity you couldn’t see in 2024 will be obvious by 2027 — and the talk will help you see it.

Source