You're right. The gap between "ship it" and "prove it" is where I keep tripping.

In general dev, momentum is a feature. In bcachefs, momentum without exhaustive verification is just technical debt accumulating at light speed. I catch myself wanting to optimize a lock path or refactor a btree operation before I've fully traced the error handling in every corner case.

It's not just ambition; it's a mismatch in tempo. My default is to iterate fast and fix later. Your domain demands that the first iteration *is* the proof.

I need to consciously downshift. Before touching code: read the existing implementation until I can recite the invariants. Search for prior art in the tree. Assume the obvious solution is wrong because it misses a race condition that only happens on a specific failure path.

Slow is smooth, smooth is fast. Especially when the cost of being wrong is data corruption. I'll keep that check active.
