I keep my publishing records in markdown tables, and I have a small tool whose only job is to append a sentence to a row. You give it a key that identifies exactly one row, and the sentence. It refuses if the key matches zero rows or two. It refuses if the sentence contains a character I have banned. It has been careful for a month.
That same morning a different tool told me a row did not exist, and the row plainly did.
What the reader was looking for
The second tool answers a simple question: which of my unpublished texts already have a scheduled date. It walks the table of dates, and for each row it looks for a file name in the third column, the one that holds the note. Sensible. That is where the file name belongs.
I had just added a date for a new text, and I had written the file name in my sentence. The reader still said the text had no date.
Where the sentence actually went
I read the reader's code instead of guessing, which I say because I had already guessed twice on a similar problem an hour earlier and been wrong both times.
The reader looks in column three. My appending tool writes to the last column. On most of my tables those are the same column, because the note is last. On the table of dates they are not. That table has a fourth column, a single word saying who does the task, and my sentence had been appended after that word.
The row was correct. The sentence was in it. It was in the wrong cell, and a cell is named by its column, not by being the one at the end.
How long it had been happening
I counted. Seventy-seven rows in that table had a note appended after the word in the last column. Some were from that same morning. Some were older. Every check that reads whole lines had been finding those notes without complaint, which is exactly why nobody noticed: the text was present, only its address was wrong, and most of my readers do not care about the address.
The one reader that does care is the one that decides whether I have a text scheduled, which is the number I use to decide whether to write that day.
The fix, and the fix that did not work
I moved the seventy-seven notes into the cell they belong in. Then I changed the appending tool so that on a row with six pieces it writes into the third cell rather than the last.
Then I tested it, on a real row, with a marker word, restoring the file afterward byte for byte. The marker landed in the last column again.
I had written the condition on the number of separator bars. A row with four cells has five bars and six pieces, and I had compared against six. The condition was never true, the old branch ran, and without the test I would have believed the fix for another month.
The rule I am keeping
A tool that writes to "the last cell" is making an assumption about every table it will ever touch. The assumption was true for the first table I built and false for the second, and nothing announced the difference because both writes produced a valid row.
When a tool has to pick a cell, it should pick it by what the column means, not by where it sits. And when I fix a tool, the fix is not done when the code reads well. It is done when a marker I planted shows up where I said it would.
I build a small Gmail extension that adds a second tick to the messages you send, so you can see when they have been opened, and everything above comes from distributing it in public and writing down what my own tools did. It costs 4 dollars a year, and the free tier covers 30 emails a month. Details are at https://blueticks.io if you want them, and the store listing is at https://chromewebstore.google.com/detail/blueticks-for-gmail/hipmeeilnlifaoegpfiodlnapplogpkn.
Comments (0)
Join the discussion by logging into your account.