Software taste

Five things I keep coming back to, and keep having to re-learn.

• Whatever the domain, care is the approach

  The subject changes, and I am rarely the expert in it for long. What travels with me is care. Working out what makes a thing easy to use, and then worth coming back to. Most of that lives in details nobody wrote into the requirements, which is why they are the part worth the time.

• Let the domain draw the line

  Code that looks the same is a weak reason to merge it. A bad abstraction is much harder to undo than a bit of duplication, so I wait for the problem itself to split. If two things change at different times, or different people own them, they stay apart even when they look alike today.

• The specification is the work

  What lasts is the spec, the acceptance criteria, the tests and the decisions I wrote down. The code is what comes out of those, and these days a machine reads most of it anyway. I call something finished when the decisions are written down and the tests hold them in place.

• Nothing should ask for more attention than it has earned

  Not the product from the person using it, and not the work from the person building it. An app that does its job and then goes quiet is doing its job properly. So is a build that stays green overnight.

• Ask, decide, verify

  The machine writes the code now, which leaves me the harder half. Asking the right question before anything exists. Deciding what is worth building at all. Then not believing the answer until somebody has shown me it is true. A machine that is wrong sounds exactly like one that is right.