"I Don't Understand" Debugging
I once heard Malcolm Gladwell claim that his father, a professor, would have never fallen for Bernie Madoff's Ponzi scheme. He felt his father was too curious and unafraid to admit when he didn't understand something. He'd listen to the pitch, then quietly say: "I don't understand that; please explain it to me again." Again and again, until the explainer gave up.
I call this "I don't understand" debugging. It's something I'm proud to have picked up watching some greats at Hashrocket. I can't always summon it, but when I can, it's magical.
When I walk into a group debugging session, I sometimes hear two programmers clashing in a familiar way.
Developer X:"I think this import statement is causing the crash."
Developer Y: "It can't be that. We do this all the time, and it's never crashed before."
This can go on forever. Nobody changes anybody's mind. You might even unearth that debugging chestnut: "This shouldn't be happening." Or: "This can't happen."
I don't understand the bug yet, but I will, because these are hypotheses! And hypotheses can be tested. Let's consider that first idea:
"I think this import statement is causing the crash."
How could we test this? Let's try removing it, or if we can't, importing our thing a different way. Instead of a default import, let's use a named import, or require! That would confirm or deny the hypothesis.
If the bug still happens in our experiment, then importing is not the issue! If it stops happening, then we've reduced the surface area of this bug to a single line of code.
Ruling it out is almost as good as not. Why? Now we can say: "We thought that this import might be causing the issue, but it isn't." It is irrelevant. We're starting to understand the issue.
Debugging is hard; if you knew what was causing the bug, you wouldn't have written it. Saying "I don't understand" permits you to be simpler than the problem. Asking simple questions and challenging entrenched assumptions can change everything.
How do we practice "I don't understand"? We can:
- State the facts ("This is crashing")
- State our assumption ("We think it's this import statement")
- Ask: how could we test this?
- Test!
- Verbalize and act on the information
Verbalizing is crucial: our minds move very quickly, but our mouths and ears don't. A Ponzi scheme falls apart when you try to describe it.
Most good experiments are simple. If you think importing is causing the issue, remove it! Comment out the whole file. There are no rules.
It can be hard to say "I don't understand." Helpfully, as your career progresses you start to believe: "If I can't understand this, it's a sign we need to break it down more." If you're speaking in my domain and you lose me, we need to back up. If not for me, then for the junior engineers who are also trying to help.
The best compliment I've received after a debugging session: "The questions you asked were really helpful." I asked them because I didn't understand.