The weight was never the textures

Every project I have finished had a moment where I was convinced the problem was the textures. Not literally, though sometimes literally. The surface. The thing you can see, and therefore the thing you can keep adjusting, indefinitely, while telling yourself it is work.

On unsent it was the dashboard. I rebuilt the delivery timeline three times. The first version was a table. The second was a vertical timeline with little connector lines between events, which I was quite proud of. The third went back to something close to the table but with better typography, which tells you roughly how much value the middle version added.

Somewhere in the third rebuild I went back through eight months of support email to see how many people had asked for a better timeline. The answer was none. Not one. What they asked for, every single time, in almost identical words, was whether a specific message had arrived and if not why not. That is a question about a single row, and I had spent weeks on the shape of the list around it.

The reason is not mysterious. The timeline was the part I could see. I could open it, dislike it, change something, and immediately feel that the product was better than it had been an hour ago. Thinking about whether delivery events could arrive out of order produced no such feeling. It produced a headache and a document, and at the end of the day the screen looked exactly the same as it had at the start.

That asymmetry is the trap. Visible work pays you back on the same day. Invisible work pays you back in month nine, when a customer asks a hard question and you already have the answer. There is no version of your brain that weights those two equally in the moment, so you have to weight them deliberately, in advance, before you sit down.

The weight was never the textures. It was always the thing underneath, the thing that could not be fiddled with. Whether delivery state was actually consistent when events arrived a day apart. Whether prayer times were right on a phone that had not seen a network since morning. Whether logging a meal took eleven seconds or forty. Those three numbers decided whether three products lived, and not one of them is visible in a screenshot.

I want to be careful here, because this is very easy to overstate into something stupid. I am not arguing that appearance does not matter. Two of these products got their first hundred users specifically because they looked like somebody had bothered, and looking like somebody bothered is itself a signal about whether the rest of it was built with care. Ugly software has to be twice as good to get the same trust.

The argument is about sequence, not importance. The surface is the cheapest thing in the whole product to change. You can change it in an afternoon, at any point, forever. The thing underneath gets more expensive to change every week it exists, because more of the product comes to depend on the shape you chose. Spending your first month on the cheap reversible thing and your ninth month on the expensive irreversible one is exactly backwards, and it feels wonderful the entire time you are doing it.

The test I use now takes about ten seconds. Before I spend a day on something I ask what breaks if I skip it. If the answer is that it looks worse, that day can wait, because that day will still be available in November and it will cost the same then. If the answer is that somebody cannot trust the output, that is not a day that can wait, because the cost of that one goes up every week.

There is a second-order version of this that took me longer to see. The invisible work is also the work that is hardest to ask for help with and hardest to show anyone. Nobody retweets a screenshot of a consistency guarantee. If your motivation comes from showing people things, you will drift toward the surface without ever deciding to, and you will have a very good reason every single time.

There is a version of this that shows up in how solo work gets talked about publicly, and it is worth naming because it feeds the loop. What gets shared is screenshots. A build-in-public timeline is almost entirely surface, because the surface is the only part that photographs. Nobody has ever posted a compelling image of a race condition they did not have. So the feedback you receive from the outside world is, structurally, feedback about the cheapest layer, delivered enthusiastically, at exactly the moment you are most susceptible to it.

I fell for this for most of a year. The days I felt best about were the days I had something to show. The days that actually moved the product were frequently days where I deleted more than I wrote and had nothing at the end except a slightly better understanding of what the problem was. Those days feel like failure while you are inside them and they are almost always the ones that count.

The second-order effect is worse than the first. If visible progress is what sustains you, you will start choosing problems that produce visible progress. That is a change in what you build, not just in how you spend a Tuesday, and it happens without any moment where you decide to make it. You look up eight months later and the product is a set of screens with very little underneath, and every individual choice that got you there was reasonable.

The counterweight I use now is a note at the top of every repository with a single number in it. Seconds to log a meal. Whether the prayer time is right with the network off. Whether a delivery answer is correct twenty-four hours later. It is deliberately one number and not a list, because a list can be satisfied selectively and a single number cannot.

That number does two jobs. It decides what to work on, which is the obvious one. It also decides what finished means, which is the one I underestimated. Without it, nothing is ever done, because there is always another pass available on the surface and the surface never stops accepting passes. With it, there is a point where the honest answer is that the number is where it needs to be and the remaining work is decoration, and decoration can wait until there is nothing more important.

One caveat, because I have watched people take this too far in the other direction. A product that is entirely substance and visibly does not care is also making a claim, and the claim is that you were not paying attention. Nobody trusts a bank with a broken layout. The surface is a multiplier on the thing underneath, and multiplying nothing still gets you nothing.

None of this makes the pull go away. I still catch myself on the fourth version of a layout, and I still enjoy it more than the alternative. The note does not stop me. It just means that when I catch myself, I catch myself against something I wrote down when I was calmer, rather than against a vague sense that I might be avoiding something.

The only defence I have found is writing down, before starting, the one number the product is judged on. Seconds to log a meal. Whether the prayer time is right offline. Whether a delivery answer is correct. Then when I catch myself on the fourth version of a layout, the note is there, in the repository, in my own handwriting, being unbearably smug about it.