✨ What is this post about: As a part of my professional growth, I make time to watch conference talks on Ruby, Rails, JS, React, tech writing, and tech trivia. Previously, I'd just watch them but now I will take and publish notes for future reference. This talk was a part of RailsConf 2021 that I'm participating in at the time of writing.

✨ Talk: 'Debugging: Techniques for Uncertain Times' by Chelsea Troy

✨ One-paragraph summary: When we learn to code, we focus on writing features while we understand what the code is doing. When we debug, we don’t understand what our code is doing. The less we understand, the less likely it is that our usual programming mindset—the one we use for feature development—can solve the problem. It turns out, the skills that make us calmer, more effective debuggers also equip us to deal with rapid, substantial changes to our lives.

✨ Impression: Chelsea is such a great speaker (charismatic, funny, eloquent, smart). This talk should be included in all bootcamp curricula. I loved it.

Table of contents:

• Notes
• Debugging Effectively
• Read more

Notes

• Compelling argument: we don't teach debugging but instead, how to implement feature, how to build something in the software that we know when we understand what the code is doing
• The video tutorials and live-coding presentations focus on the working code and on the code a person have written already a number of times, avoiding all error messages and following the happy path only
• "We know what we are writing and that's what gets modelled in programming education. But that's not the case when we're writing code on the job."
• "We spend a lion's share outside of the comfort zone of the code we understand"
• "Debugging feels hard in part because we take skills that we learned from feature buiding in the context of certainty and attempt to apply them in a new context, a context where we don't understand what our code is doing, where we are surrounded by uncertainty"

Debugging Effectively

1. We need to acknowledge that we do not already understand the behavior of our code
   • we think we are supposed to know how to write the solution because that's all we've seen
   • "we better hurry up and figure it out!" <- speed is precisely the enemy of the insidious bugs
   • "when my feelings of inadequacy screeched at me to speed up, that's when I most needed to slow down, to figure out why exactly I wasn't getting what I expected. I needed to get out of the progress mode and into the investigation mode."
2. We need to switch modes from focusing on progress to focusing on investigation
   • the standard debugging strategy: we try the most probable solutions to our bug, one by one; it won't work if we don't understand the behavior our code so we circle around ideas
   • instead of trying to fix the problem, we need to switch to finding the problem (specific invalid assumptions we're making about this code)
   • binary search strategy: run the code, choose a place more/less in the middle between where it still runs and where it bugs out, investigate the code (code flow) there; \
   • insidious bugs come from inaccurate assumptions -- we are looking in our code but the problem is rooted in our understanding
   • it's difficult for us to detect that our assumptions are wrong because it's difficult for us to detect that we are making assumptions at all
   • stop, list our assumptions, use tools to test them (automated tests, manual run-throughs, breakpoints, print statements, logging, changing small things)
3. We need to be able to identify what is the truth and what is our perspective
4. We need to be able to see how the things we're doing now serve longer-term goals

• "Even if I fail, I have taken a step forward"

Read more

• Chelsea's blog: I love it all.