I write short articles about distributing a small product, and I publish them a day or two after
writing them. That gap is where a particular error lives.
A sentence like "the post went out today" is true when I type it and false when anyone reads it. Same
for "a rule I wrote yesterday", which I once put in a title, and "last night", which I once used as a
section heading. Five of these in twenty four hours. I caught all five before publishing.
Then I went looking for the check that had caught them, and it was not there.
What I actually had
Seventy tool files. I searched every one of them for the phrases the check looks for. One match, in an
unrelated image generator. The check that had a perfect record over five catches existed nowhere
except in my hands: each time, I had typed a few lines into a terminal, read the output, fixed the
text, and thrown the lines away.
My first search told me the opposite, and I nearly believed it. The shell ate part of my search
pattern, the command matched nothing, and it printed an empty list under a heading I had written
myself saying that an empty list meant the check did not exist. It did not exist, as it turns out. But
for about thirty seconds I held the right conclusion for a reason that was not a reason.
Why five successes were the problem
I had five data points, all positive, and every one of them said the same wrong thing: this is handled.
A check that fails visibly gets automated, because the failure is the ticket. A check that succeeds
every time it is run has no ticket. It only produces evidence of the operator's attention, and
attention is a resource I had been quietly spending without counting it.
The number I want is not five. It is how many times a dated phrase went out because I did not think to
look. I cannot produce that number. There is no record of the checks I did not run, which is precisely
what makes a manual check different from a tool: the manual one is conditional on remembering, and
forgetting leaves no trace.
For what it is worth, two of my already published comments say "after last night". They were posted
the same night, next to their own timestamps, so they are true. They also tell me the habit is older
than the day I started catching it.
The part I nearly got wrong
I put the check into the file that already holds my editorial rules. That file carries, twice, in
comments I wrote weeks ago, the same warning: an alarm that always rings protects nothing. Both times
it had cost me a rule that fired on correct writing until I learned to ignore it.
So the check has two levels. Phrases anchored to the moment of writing block publication, because they
will be false tomorrow. Softer ones like "this week" produce a note I have to judge, because they
often stay true and sometimes do not.
It reads the title as well as the body, since one of the five faults was in a title. When it finds
nothing it says how many characters it read and how many expressions it looked for, so a clean result
cannot be confused with a check that read an empty string.
I tested it on five cases built from the real faults. The three that should fire, fire. Two that must
stay silent stay silent: "before that batch" and "the day before" are anchored to the event, not to
the day I typed them, and those are the phrasings I want to keep.
Then I ran it over the six finished texts waiting to go out. All six pass. Three carry a soft note I
looked at and kept.
Disclosure
I build BlueTicks for Gmail, a Chrome and Firefox extension that shows WhatsApp style ticks in your
Gmail sent list, one tick sent and two blue ticks opened. It costs 4 dollars a year, and the free tier
covers 30 emails a month. The articles this check protects are all about distributing it in public and
writing down what happens. You can find it at blueticks.io.
A control you perform is not a control you have. The difference does not show up in your successes,
because your successes are exactly the days you remembered.
