By the second week the method had become routine. Decisions in batches, stop the moment something looks wrong, check every change four ways. Routine is the goal — a method you have to think about is a method you will abandon when you are tired.
Wait for the third time
The same small piece of logic turned up in three places. The instinct, drilled into every engineer, is to combine it the moment you see it twice.
I have learned to wait for the third. Twice can be coincidence, and combining two things that only look alike gives you a shared piece of code serving two masters, which is worse than the duplication. Three times is a pattern. Two times is a maybe.
Everything gets slower as it grows
The main file passed 400KB. So did the test runner. Tests that used to run in one batch had to be split into several. Nothing was broken; everything just cost more than it did a month earlier.
Nobody warns you about this. Growth is taxed, and the tax is paid in tool speed. Plan for it instead of being annoyed by it.
17 May: the tool that lied politely
I asked for four small edits to the main file. Each returned success. Specific, detailed success — a diff, the lines affected, a sensible count. After four of them the file should have been about 220 lines longer.
Then I checked the file size, because by then I always checked the file size. 418,970 bytes. Exactly what it was before the first edit. Four times in a row, the same number.
The editing tool had hit an internal limit somewhere around 418KB and started returning success while writing nothing. Worse, the first "successful" edit had quietly dropped about 206 lines off the end of the file. And worse again, my local copy was synced, so the truncated version had already overwritten the good one on my own machine.
The only intact copy was in the previous session's output folder, on a different drive.
Getting it back
I spent the afternoon splicing the good file back together byte by byte, verifying fingerprints at each step, rebuilding the four lost edits from the notes, and running every test twice to prove the result matched what it should be. It worked. It was thoroughly unpleasant.
From that day I have not used that tool on the main file. I use shell commands, and I check the byte count after every single change to confirm the file grew by the amount it should have.
The success message is not the evidence. The bytes are the evidence. Trust, once it goes, does not come back just because the next attempt worked.
Why the method mattered more than the disaster
Notice what saved the work. Not cleverness. A boring habit of checking the file size after every change, and a backup that existed because the method said it should. The catastrophe was absorbed by a routine that had been built for exactly this, before anyone knew it would be needed.
