← Index

How I Work

Spec → Tests → Code

TL;DR - Spec-driven plus test-driven development, in that exact order, is the single highest-leverage approach I've discovered. The reason is psychological, not just procedural - once I start coding, my brain stops thinking. So all the hard thinking, the design and every edge case, has to happen before the first line of code, while I'm still in thinking mode.

SpecTestsCode

The insight

Here's the trap I kept falling into. I'd start coding with a rough idea, and the moment my hands were on the keyboard, my brain flipped from thinking mode into executing mode. In executing mode you don't discover edge cases. You just make the happy path work and move on. The bugs that ship are always the cases you never stopped to consider, because by the time you're deep in implementation, you're not looking for them anymore.

The fix isn't "think harder while coding." You can't. The fix is to front-load all the thinking into a phase where the code doesn't exist yet.

Executing mode
Thinking mode
Hands on the keyboard
Code doesn't exist yet
Happy path only
Every edge case on the table
Bugs ship
Bugs die on paper
Expensive to change
Cheap to change

The workflow (what I run in my most productive hours)

  1. Iterate on the spec. Get the feature clear and complete on paper first - the end-state, the flow, the decisions. The spec is the understanding, made explicit and revisable before anything is expensive to change.
  2. Think through the tests - every edge case, everything that can go wrong. This is the step people skip, and it's the highest-leverage one. Before writing implementation code, I enumerate what could break - empty states, bad input, concurrency, permission boundaries, the weird flows. This is where quality is actually decided.
  3. Only then, execute the coding. With the spec clear and the edge cases already mapped into tests, implementation becomes the easy part. I'm just filling in a shape I already understand, against tests that already know what "correct" means.

Why it works

The effort goes in where it counts - upstream, while my brain is still in thinking mode and the code is still cheap to change. By the time I'm coding, the hard problems are already solved on paper. The result is the highest-quality code I produce, because the quality was designed in before the first keystroke, not debugged in afterward.

Spec, then tests, then code. In that order. That's the whole workflow.

← Back to all