Why the first version is always the frightening one
Notes on starting things badly on purpose — in code, in running, and in the parts of life where nobody hands you a specification.
The first time I had to design a service that would carry real production traffic, I spent two days not writing it. Not blocked, not researching — just avoiding the moment where the file exists and is wrong.
The specification you don’t have
Engineering has a comfortable habit: you get requirements, and the requirements imply a shape. Outside of engineering the requirements are missing, and the shape only appears once you have made something ugly enough to react to.
A first version is not a claim about your ability. It’s a question you’re asking the problem.
The three things that reliably get me past the first hour:
- Write the interface before the implementation — even if both are wrong.
- Set a timebox you’d be embarrassed to overrun.
- Tell one person what you’re doing before it works.
// the honest first draft
func Process(ctx context.Context, img Image) error {
return errors.New("not yet, but soon")
}
Running taught me the same thing faster than work did. The first kilometre is always the argument; the rest is just distance.