You will fall in love with the wrong thing

There is a failure mode that only exists if you both design and build. It is the most enjoyable mistake in the job, which is exactly why it is dangerous.

You build something lovely. A transition that springs just right. A loading state that feels alive. Then, quietly, you start working backwards. You go looking for the reason to ship it. Not because the reason came first, but because the alternative is deleting work you enjoyed making.

This is where you often end up in the trap. You fall in love with an implementation, then reverse-engineer a justification for it.

A designer who only designs is protected from this by handoff. They pass the direction to an engineer, and that handoff is a checkpoint. Someone else has to be convinced before the thing gets built. The friction is the safeguard, even when it does not feel like one.

When you do both, there is no handoff. No translation step. No moment where another person asks why you are doing this. You go straight from idea to working code, alone and fast. The thing that makes you valuable is the same thing that removes the checkpoint.

So you build first and reason later. And reasoning after the fact is not reasoning. It is defence.

The tell

You can catch yourself doing it. The clearest tell is the order of events. If you are explaining why a thing is good after it already exists, you have done it backwards. The justification turned up to protect the work, not to test it.

The other tell is how it feels. A decision made for the right reason feels neutral. You would be equally happy to cut it. A decision you are defending feels personal. You notice you want to win the argument. That want is the sunk cost talking, and it is worth learning to recognise the sensation, because it is the only early warning you get.

I’ve built multiple animations for the Search Assist answer module I work on that I’ve been quietly proud of. Spring-driven, velocity-aware, the kind of small physical details almost nobody notices and I care about anyway. They were all equally genuinely nice.

They also solved nothing. The numbers didn’t move. People didn’t behave any differently with it than without it. I had built it because I wanted to build it, then spent longer than I will admit hunting for the metric that would let me keep it.

There was no metric so I deleted most of them. It still stings a bit, which is roughly how I know it was the right call.

The fix

Write-first design breaks the loop, and it breaks it at the only point where breaking it is cheap.

If you commit to the reasoning in prose before you commit to it in code, the code ends up serving the decision. You build the thing the argument asked for. Do it the other way round and the argument ends up serving the code, and an argument that exists to protect something already built is not worth much.

The rule is simple. The reason comes before the thing. If you cannot write down why an interaction should exist before you build it, build something else. And if you have already built it and the reason still will not come, the kindest thing you can do is delete it.

The work you enjoy making is not always the same as the work worth shipping. Sometimes they are the same thing, and those are good days. The discipline is being able to tell when they are not.

The only way to tell is to have written the reason down before you fell in love. After that, you are not judging the work any more. You are defending it.