How I plan a system before I write any code

I draw before I type. Not because I'm a particularly visual thinker, but because most of the cost of a system lives in its data movement, and data movement is much easier to reason about as arrows on a board than as functions in a file.

The flow comes first. Then the seams between subsystems. Then the failure modes — what happens if this stage dies, what happens if that input is malformed, what happens if a worker is restarted mid-job. Only then, code.

It feels slower. It is, in fact, much faster. The bugs you avoid by getting the diagram right are the bugs that would otherwise live in production for months.