Recently I’ve noticed a few cases where I’ve been solving a problem and determined that some approach doesn’t work, only to get stuck on other approaches too and finally return to the supposedly broken approach and realize that it actually works. Occasionally I’ll explicitly set out to rewrite a piece of broken code using the same approach and it’ll work and I can compare the two, but for most problems the history will be gone and I’m left wondering what I was doing wrong before.
This doesn’t only happen for programming problems, either. I was searching through my journal looking for something else yesterday and happened to see an unsuccessful skin-care regime I undertook about a year ago. It called for the use of two products and I followed it for a week but it worsened my skin’s condition so much that I stopped. A few months ago I started using one of the products alone, having completely forgotten about my prior experience, and it proved super effective. I likely could have seen those results a year earlier if I’d changed one variable at a time and hadn’t conflated the failure of the combo with the failure of each individually.
These false negatives for good approaches aren’t surprising: I fail to solve many problems on the first try even when I’m using an approach that’s been shown by others to work. And when it’s unclear why something is broken, as it often is, it’s easy to get the impression that the approach is hopeless without having enough information to confidently rule it out. The best strategy I can think of to mitigate the cost of these false negatives is to take better notes. I often take notes of the approaches I’m trying, but clearly I need to be more disciplined in noting why I abandon an approach as well so I can judge later whether I did so mistakenly.
See also: Nelson Elhage’s Lab Notebooking for the Software Engineer, which gave more purpose to my existing notetaking habit.