The Underconfidence Trap
I’ve just spent a couple of hours trying to track down an error in some Java code I’m writing that uses generics (an area I do not know as well as I would like).
I’ve been tearing my hair out, assuming that the problem must lie in something I’ve misunderstood about the new area. The code implementing generics looked correct, but then what do I know? It’s not an area where I’m confident so I must have made some kind of idiotic, beginner’s mistake with it that I’m just not noticing. Or so I assume.
I refactored the code substantially. The bar stayed red. The same test kept breaking.
And then I found the error. A typo in the unit test itself. My code had been generating the right results all along but I had been checking the wrong thing.
When I’m confident of something and there’s an problem, I check the simplest things first. But when I’m not confident, I assume that the problem must lie in the area I don’t fully understand and dive straight into that without pause to check anything else.
I’ve fallen into this trap often enough that perhaps I should consider it a personal anti-pattern. Hopefully articulating it is the first step towards breaking it.