Skip to content

approach

This is how I take a problem from the first question to something people rely on. Most of the work happens before and after the code.

  1. 01

    Find the real problem

    A request is often a solution in disguise, so I first ask who has the problem, what it costs them, and what can't change. I write that down, then test my riskiest assumption while it's still cheap to be wrong.

    I askWhat has to be true for this to count as solved?

  2. 02

    Decide what's hard to undo

    Two things cost the most to change: the shape of the data and how the parts talk to each other. I settle those before I draw a screen and note what I rejected. Everything else gets the simplest option that's easy to reverse.

    I askWhen a part fails, what does the user see?

  3. 03

    Build in small, tested steps

    I get one thin path working end to end, then widen it in small changes someone else can review in one sitting. Tests go in with the code, and I hold off on abstractions until the same need shows up twice.

    I askIf this change is wrong, how quickly will I find out?

  4. 04

    Own it after launch

    I ship with a way to roll back and enough logging to see what breaks before a user tells me. Then I watch how it's used, fix what hurts, and stop when the problem is solved, not when the ideas run out.

    I askDid this solve the problem I wrote down at the start?