Building software is mostly finding out that something you were certain about is wrong. Here are three from Buhata that were worth the trouble of understanding properly.
The hand that would not drag
The desk on a computer is a canvas larger than the screen, and there is a hand tool for moving around it. It did nothing. I looked at the code that wires it several times and the code was correct.
The cause was a variable I had deleted by accident in an earlier change, several versions before. The first line of the wiring function referred to it, threw an error, and that error was caught by a safety wrapper that swallowed it silently. So the feature read perfectly and did nothing at all.
The lesson there had little to do with the variable. A guarded call to something which no longer exists looks exactly like working code, and only fails where nobody is watching.
The headline nobody could read
The front of the website had white text on a mint background. I had looked at it many times.
Measured, it came out at 1.18 to 1, against a recommended minimum of 3 for large text. Calling it hard to read would be generous. It was barely on the page at all. Nobody had noticed because everybody involved already knew what it was supposed to say.
The logo that was not centred
I kept nudging the app icon left and right because the letter looked off centre, and it kept looking off centre.
The tool I was using to measure it was reading the dark letter through a semi transparent yellow circle behind it, so it thought the shape was thirty one pixels wider than it is. Every adjustment I made was an argument with an instrument that was lying to me.
If a thing can be measured, measuring it beats agreeing that it looks about right.
What I do about it now
Each of those is a test that fails if the fault comes back. That is the only durable answer I have found. A fix you remember is a fix that lasts exactly as long as you remember it.
