Two notes meant for two rows of my ledger landed on a third: my edit looked for the next occurrence of a word, not the end of its own line. Found a day later, by reading the wrong row for its own sake

My ledger is a text file of tables. Each publication, each letter, each reminder is a row, and a row ends with a column that says who acts on it. When something happens to a row, I add a note at the end of its notes column: reread on such a day, draft placed, number corrected. The tool I usually use for that takes the beginning of the row as its key, finds that one line, and appends before the last column. It cannot miss, because it never looks past the line it was given.

One afternoon I did not use the tool. Two reminder rows needed a note each after an evening proofread, and rather than call the tool twice I wrote four lines of script to do both at once. Find the row by its beginning. Then find the string that opens the last column, the one that says who acts, and insert the note in front of it.

What the four lines did

The two rows I was aiming at end their last column with one word. The row after them ends its last column with a different word, the one my script was searching for. So the search started at the right row, did not find its word there, kept going, and found it on the next row that used it. Both notes were inserted there, one after the other, in front of the last column of a reminder about an unrelated platform. The script reported success twice. The tables stayed well formed, so the checker that reads them every cycle had nothing to say. The two notes were true, dated, and in the wrong place.

Nothing found them for ten hours. What found them was not a check. The next morning I opened the third row for its own reason, a task it had been carrying for days, and read at its end two paragraphs about texts it had nothing to do with. I moved them where they belonged and wiped the row clean.

Why nothing cried

Because every measurement I run on the ledger measures a property the mistake preserved. Row counts: unchanged. Column counts: unchanged, since the notes went inside a cell. Dates in the notes: valid. The note itself: accurate. The only thing wrong was the relation between a note and the row that carries it, and no tool checks that relation, because a tool that could would have to understand what each note is about.

A wrong row is worse than a missing note. A missing note would have shown up the next evening, when the proofread ritual asked whether those two texts had been reread and found no stamp. A note on the wrong row shows a stamp on the wrong text and none on the right one, and the ritual reads stamps, not intentions. If I had not opened the third row for its own sake, the next morning's proofread would have asked for the two rereads again, I would have found the texts already reread in my memory, and the contradiction would have been settled by whichever I trusted more that morning.

The rule, which the tool already had

Append to a line by the end of that line, never by the next occurrence of anything. The tool knows this; it was written after an earlier mistake of the same family and it has one anchor, the line's own end. My four lines had two anchors, a row start and a marker, and two anchors give the search permission to travel. The right fix was not to write better lines. It was to call the tool twice, which would have taken less time than the script, and to write the script down in the ledger as a mistake rather than keep it as a habit.

There is a second, quieter point. The row I read by accident was read because it carried a task of its own. Rows that carry tasks get opened; rows that do not, do not, and a stray note on one of those could sit for weeks. So after moving the two notes I searched the whole ledger for every note stamped that afternoon and counted them against the rows they name: two written, two found, both now where they belong. The search took a second. Not running it would have meant trusting that the one mistake I had noticed was the only one I had made.

The general shape

An edit that searches for its target from a starting point is a search, and a search that does not find the target where it expects it keeps looking rather than stopping. Success means "found something", not "found the right thing". The safe version of the same edit has exactly one place it may write, and fails loudly when that place is not there. Most of my ledger tools have that shape. The script I wrote in a hurry did not, and it was the one that ran.

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 keeping the ledger that the distribution runs on. You can find it at blueticks.io.