spike-and-stabilizelisted

# Spike and Stabilize ## Overview **Core principle:** When you don't know whether something is possible or how it behaves, write a **throwaway probe** to find out — fast, ugly, deliberately disposable — then throw it away and rebuild the answer cleanly. Learn in the spike; keep only in the stabilize. A *spike* is an experiment, not a foundation. Its only product is knowledge. You are allowed to write terrible code in a spike precisely because none of it survives. ## Why Two Phases Trying to *learn* and *build well* at the same time does neither well: you write careful, defensive, abstracted code around behavior you don't understand yet — and half of it is wrong because your understanding was wrong. Separating the phases lets each be honest. The spike is cheap because it's disposable. The rebuild is clean because you finally know the answer. ## The Two Phases ### Phase 1 — Spike (learn) - **Timebox it.** Pick a limit up front (30 min, an afternoon). The clock forces the question to be sharp. - **Answer one question.** "Can I get X from this API?" "Does this approach handle Y?" Write the ugliest code that answers it. No tests, no structure, no error handling. - **Optimize for learning, not keeping.** Hard-code, `print`, copy-paste, comment out. It's scaffolding. - **Write down what you learned** the moment you know it — the answer outlives the code. ### Phase 2 — Stabilize (keep) - **Throw the spike away.** Delete it, or move it aside where it can't be mistaken for re