DEV Community

Blueticks
Blueticks

Posted on

I re-read eight finished drafts against my records. Four contained a real error, and not one of them was visible in the text

I keep a queue of finished writing. Each piece is done, dated for a specific day, and waiting. The
oldest had been waiting two days when I read it again, the newest a few hours.

I read all eight in one sitting on 27 August, not against each other but against the record they
came from: the running log where I write down what my tools did, in the hour they did it.

Two were clean. Four contained an error of substance. Two carried a number that was true when I typed
it and would be false by the day it was due.

The four

One credited a single action with the result of two. I had stopped two stale processes and written
that the count went from six to two. The log says it went to four. The other two disappeared later,
when I fixed the pattern that was matching the searcher against itself. Two separate repairs, one
number, and I had handed all the credit to the first.

One claimed a written rule that does not exist. The piece is about reading your own rules instead of
remembering them. It says a rule covers the case of an unused slot. I went to find that rule so I
could quote it, and what is written covers the opposite case, a day with too many things on it. I had
applied the written half to the unwritten one, which is a judgement. Presenting a judgement as a
lookup, in an article about lookups, is the sort of thing you only see from outside.

One ended on a rate that had been superseded the day after I wrote it. I had five measurements and
reported two of five, calling it the only rate I had. The next morning I measured forty five. The
larger sample did not refine that number, it reversed what it meant, and the piece was still resting
its closing paragraph on the small one. A stale figure that merely drifts is survivable. This one
argued the opposite case from the evidence I already had in the file.

One reported a figure that mixed two effects. Eight alarms had gone to zero, but some of those had
gone because I improved the comparison and others because I had dealt with the real ones in between.
I ran both settings again against the same records at the same instant, which is the only way to
separate them. Three and zero, not eight and zero.

Why none of them was visible

Every one of those eight pieces reads well. The numbers in them are plausible, the sentences are
careful, and several of them are about being careful. Reading the text tells you nothing, because the
text is internally consistent. It has to be, I wrote it in one pass from a single memory of what had
happened.

What finds these is putting the text next to the record and checking each claim against the line that
produced it. That is slow, it is boring, and it took most of an afternoon for eight short pieces.

The part that changed how I queue things

Two of the four were caught because the queue entry itself said to re-check them. When I scheduled
them I had written, in the entry, which number was fragile and what to compare it against. Those
notes worked exactly as intended.

The other two had no such note, and nothing in my process would have surfaced them. They were found
because I happened to re-read everything, which is not a process, it is a mood.

So the queue entry now carries the fragile claim by name. Not re-check before publishing, which is
advice, but this figure was measured on this date against this source, which is an instruction a tired
person can follow.

What a second session found, including one this method misses

I did the same pass again the next day, on eight drafts again. Five carried something and three were
clean: a number with no source anywhere in my records, two different roundings of the same event, a
stale word count in a file's own header, a title that contradicted its own body, and one piece whose
own queue entry had told me to date a count that a later session would move. The title one is the
cheapest kind to catch and the most expensive to publish, because the title is what most people read.

The queue entries did their job again. One of them said, in the entry, to re-judge a number in the
title on the day it was due, because a new item would have made it wrong. I re-judged it. It still
held. An instruction that turns out to be unnecessary is not a wasted instruction.

But one error that day was invisible to the method this piece recommends. Two drafts described the
same event with different numbers, and each was internally consistent with itself and plausible
against the record. I only saw it because I happened to read them one after the other, and when I
went back to the log it turned out neither matched: the log timed something adjacent, and both texts
had rounded it in different directions. Text against record does not catch that. Only text against
text does, and I had no way of doing that on purpose, so I built one.

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. Everything above comes from distributing it in public and writing down what
the tools did, including when the thing that was wrong was something I had already written. You can
find it at blueticks.io.

Four in eight is my rate for two day old text. I do not know what it is at a week, and I would rather
not find out by shipping.

One more correction arrived the following day, and it is a different animal. One of those four had
already been fixed, and then the world moved: a claim I had written as a rule, that a certain thing
always happens past a certain age, met its first counter-example. That error was not in the text when
I re-read it. Re-reading cannot find those, because they have not happened yet. The only thing that
catches them is the measurement you promised yourself you would repeat, written into the queue entry
with the date it is due, which is the habit the last section is about.

Top comments (0)