Ship it,
then prove it.
- 01
Read the real system first
Before proposing anything I read the code, the migrations and the last six months of commits. Most briefs describe the system someone meant to build.
- 02
Write the spec, then the plan
A design document that survives review, then a task-by-task plan. Both are committed, so the reasoning is auditable later instead of living in a chat log.
- 03
Test first, commit often
The failing test comes before the implementation. Small commits mean a bad decision costs one revert, not one rewrite.
- 04
Measure what it removed
A shipped system that nobody can point a number at is a guess. Instrumentation is part of the build, not a follow-up ticket.