This week’s Classic of the Week is Rich Hickey’s 2010 Clojure Conj talk “Hammock Driven Development.” It’s one of the most-cited talks in the Clojure community and — read charitably — one of the least dated pieces of software-engineering advice from that era. Sixteen years on it reads almost eerily well as a critique of “just tell the agent to build it” culture: Hickey’s whole thesis is that the important work happens away from the keyboard, and we’ve built an industry that pretends otherwise.

The setup: problems, not code

Hickey opens by drawing a hard line between two activities that look similar and are not: solving problems and implementing solutions. Typing at a computer is the second one. The first one — figuring out what problem you actually have, what shape a solution would need, what tradeoffs are on the table — is a different mental mode, and it doesn’t happen fast.

Understand the problem, not the code

His frame: most of the mistakes he sees in software (and, notably, in his own work) come from skipping the first activity because typing feels more productive. TDD, agile ceremonies, sprint-shaped work — Hickey argues these are often defenses against the discomfort of not knowing what you’re building yet.

The waking mind: analyze, catalogue, compare

The awake phase — analyze, catalogue, compare

The first half of the talk is about the awake thinking practice. Hickey walks through what you actually do at a desk when doing this well:

  • Analyze the problem — force yourself to write down what you know, what you don’t know, what’s assumed. He is scathing about the tendency to jump to “we’ll use MongoDB” before naming the actual constraints.
  • Catalogue prior art — read what other people did on adjacent problems. He is equally scathing about the reverse tendency: reinventing without looking.
  • Consider at least two solutions — if you only have one, you don’t understand the problem yet.
  • Communicate with a peer, but be careful — pair-programming-shaped discussion often just narrows the option space prematurely.

At least two solutions

The sleeping mind: the actual hammock

The hammock — background processing is a real thing

The second half is the memorable bit. Hickey argues, with the caveat that he is not a neuroscientist, that the background processes of your mind — the ones that run while you’re not consciously thinking about the problem — are the ones that solve the hard parts. His empirical evidence is the “wake up with the answer” experience most engineers recognize.

The claim is not mystical. It’s a specific engineering discipline built around it:

  1. Load the problem carefully. Spend real time (an hour, a day) making sure your awake mind has actually taken in all the pieces. This is the analyze/catalogue/compare pass.
  2. Stop. Do not force. Go for a walk. Sleep on it. Take a hammock.
  3. Come back with a notebook. The insight appears during a shower or a walk, and it will evaporate if you don’t write it down inside about ninety seconds.

Hickey is emphatic that step 1 is the price of admission. You cannot skip loading and expect the background process to have material to work on. The hammock only works after the work.

Why it holds up in 2026

Waking up with the answer — the actual product

The reason to re-watch this talk today isn’t nostalgia — it’s that the current wave of agentic coding tools makes it easier to skip the loading phase. You can now shortcut awake-mode thinking by delegating to Claude Code, Cursor, or Codex. Hickey’s warning maps directly: if you never load the problem, the background process has nothing to churn on, and you end up with fast implementations of ill-posed problems.

The talk also predates — and quietly diagnoses — modern “prompt engineering.” Hickey’s advice for how to communicate a problem to another human (“state the problem, not your candidate solution”) is the same discipline that turns out to matter for agents. If you can’t state the problem cleanly to a colleague, you can’t state it cleanly to an agent either.

Key takeaways

  1. Solving and implementing are different activities. Typing feels productive; it isn’t the hard part.
  2. The waking pass is non-negotiable. Analyze, catalogue prior art, compare at least two solutions, communicate.
  3. Never leave with one solution. If you only have one, you don’t understand the problem yet.
  4. Load the problem before you stop. Background processing needs material to work on.
  5. Stop. Actually stop. The insight comes when you’re not forcing it — hammock, walk, sleep.
  6. Capture within 90 seconds. The answer arrives and evaporates fast. Notebook on the nightstand.
  7. The advice holds under agentic coding. Skipping the loading phase is easier than ever; the price of skipping it is bigger than ever.

Source