Weekly Reflection #30 - Think Before You Debug
Each week, I share one insight. One piece of wisdom. One question to reflect on. (and a little Lagniappe)
Insight
My favorite debugging story comes from Rob Pike when he recounted a time he was pair programming with Ken Thompson at Bell Labs. Pike was at the keyboard. When something broke, he'd immediately dive into stack traces, print statements, and the debugger. Ken would simply stand behind him and think, ignoring the code they'd just written. Then, often before Pike had finished reading the trace, Ken would say, "I know what's wrong." And, he was usually right.
Ken was holding a model of the code in his head. When something broke, the bug revealed itself in that model before it appeared in the code. He'd work out how the failure could even happen, and the gap that surfaced was usually a deeper flaw than whatever showed up on screen.
I've never regretted taking the Ken Thompson approach. It feels slower to sit and think before you start poking. But those quiet minutes are how you fix the design instead of patching the symptom it threw off today.
Wisdom
Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?
Brian Kernighan, The Elements of Programming Style
Reflection
What are you reacting to right now that deserves a step back first?
Lagniappe
- Feeling stuck? If you need someone to talk to, I coach software engineers at Leland, and I'm leading a free workshop on Thursday, July 2nd at 4PM Central: How to Stand Out as a Software Engineer (and Have Fun Doing It). Come hang out and bring your questions.
- Book Overflow is 2 years old! This week we reflect on many of the 45 books we've read on the podcast.
- As always, I'd love to hear your thoughts. Reply and let me know what resonates.