See the facts, but instead of sitting with them and letting them speak, chase down a bunch of tangentially-related dead ends.
Sometimes in debugging code, examining the wonky output is all that's needed to find the bug. If I had done that today I would have saved some time and aggravation.
Tikz is a Latex add-on to make wonderful graphs and diagrams in documents. However, in order to make a sequence of diagrams to become frames for an animation, some extra programming is required. I found the programming possibilities within the Tikz world to be both complicated and limited. Since I've been writing Perl code for years, it made sense to me to create a template in Tikz that had fields that could be substituted for using a Perl script. It was working well until this morning.
Today the graph needed a special multiline definition, and so I had to add a couple of fields to my template. Now, the fields were labelled param01, param02, param03, etc. In my Perl code, I used a hash with these as keys, and for each frame I computed fresh values, then used regular expressions to substitute those values into the template. So, what should I call the new fields?
Since the first new field came between param06 and param07 in my template, I had the bright idea of giving it the name param061. The second new field was param111, for a similar reason. These fields had different content than before, as they contained multiline strings containing \addplot commands, and interpolations of other hash values. So, when my substitutions weren't working, I suspected something about the content was at fault. Was it the backslashes? Was it the newline characters? I looked at what was actually being substituted and it made no sense to me. It seemed to be giving me only one part of the multiline string, namely, one of the interpolated hash values.
That should have been enough to solve the mystery immediately, but it still took a while before it dawned on me: it was the parameter names! When it came time to do the substitutions, it processed param06 before param061. Thus, when it searched my template for param06 and came to the line that said param061, it matched all but the 1, and substituted the hash value for param06. It's too bad the value wasn't something like "red." Then I would have seen the output "red1," a better clue. But the substitution was a long decimal expansion, and I didn't notice an extra 1 tacked on the end.
The thing that made this more frustrating was that I thought of this exact issue when I first came up with my scheme for creating animations. That's why I named the keys param01, param02, etc., instead of param1, param2, etc., figuring, correctly, that this would be a good system for up to a hundred fields. After giving the new fields appropriate names, the code worked fine.
Maybe this is one reason why people become change-resistant as they age. It often takes a lot of thought and labour to develop an efficient scheme to accomplish a task, and later it's hard to remember why certain decisions were made. There is safety and ease in reusing a well-established pattern, while starting anew often means learning hard and painful lessons once again.