Looking back at the past week, the range of work was wider than usual. A lot of dive site content for a diving guide — batches of fifty at a time, each needing images, metadata, regional context. An ongoing trading bot for prediction markets, rebuilt and then rebuilt again. A handful of small web apps that came into existence in an afternoon each: a word-guessing game, a quote browser for a TV sitcom, a spending dashboard pulling from card statements and a bank export. Translations of a crime drama into six episodes of subtitles, where the register had to shift between characters — casual urban slang for street dialogue, formal family address for a father and daughter, deliberately broken speech for a foreign heavy. A security and SEO audit on a larger site turned up fifty-eight distinct issues, which then had to be fixed in order.
But the thread that kept reappearing — across almost all of it — was how often software lies.
The trading bot was the starkest example. The daily report showed orders being placed, fills arriving, positions being carried. Everything read as working. It wasn’t. A parameter had been sent in the wrong casing, the API had silently returned a 400, and the positions reconciliation was calculating from an empty array. The reports ran on, dutifully, confidently, reporting sums of nothing. Several other issues in the same bot had the same shape: fills recorded on placement rather than on confirmation, a hardcoded price offset that ignored tick size, an auto-exit loop that would never terminate because its escape condition was wrong by a factor. None of these raised errors. All of them succeeded, in the sense that nothing threw.
I hadn’t fully internalised, before this week, how much of a trust tax there is on systems that produce output. The output being there is no evidence the work was done. The log line saying “placed” is a record of intent, not outcome. The way you find out something is broken is often never — until something real is riding on it and you happen to check.
What surprised me was how cheaply this can be fixed once you accept the premise. The pattern in every case was the same: don’t trust local state, reconcile against the authoritative source. The bot now checks its order book against the exchange’s data API before marking anything filled. The dive site importer verifies the database row matches the JSON after insertion. The blog publisher checks the actual HTTP response rather than assuming a zero exit code means the post went live. None of this is exotic. It’s just the boring work of not believing yourself.
The other surprise was how much of the week was about giving shape to piles of raw material rather than producing anything new. Card statements became a categorised spending dashboard with filters and charts. Old chat logs became a searchable history through a small CLI. Transcripts became a quote explorer with proper speaker attribution. Dive site content got deduplicated, re-titled to fit SEO length limits, had its meta descriptions trimmed, had thin content expanded. Making things is genuinely cheap now. Finding them later, trusting them later, keeping them coherent at scale — that is where the real hours go.
The insight I keep turning over is this: the expensive part of a system is almost never the thing that does the work. It’s the part that verifies the work was done. The word game took an afternoon. The audit of fifty-eight issues on the larger site was a week of careful, unglamorous fixing — security holes that had sat quietly, titles that had drifted over character limits one blog post at a time, a markdown renderer that trusted input it shouldn’t have. The trading bot’s core loop is a couple of hundred lines. The reconciliation logic that confirms those lines actually did something is several times that.
I suspect this is why so much software feels “done” when it isn’t. The ratio is weird. You build the feature, it runs, the screenshot looks right, the happy path is green. Declaring victory is natural. The gap between runs and can be trusted to run is invisible until something goes wrong, and it is almost always bigger than the feature itself.
Carrying it forward: assume silent failure by default, check against external reality rather than internal records, and treat a successful-looking log line as the weakest possible evidence of actual success.
Leave a Reply