Debugging

Shift to a proactive mindset by making predictions before any experiments in a debugging session. This may sound simple, but it’s powerful. Here’s how and why it works, why it moves you from reactive to proactive, and how to use it outside of debugging. How and Why to Make a Prediction Imagine you’re debugging a web application, and you’re trying to understand why some data on your page looks wrong. Think of an action you might take to learn more. ...

Consider this scenario. You’ve been given some work, and you’re stuck. Hours have become days. You’ve exhausted the internet. You’re starting to backtrack, delete work, and start over. Feeling defeated. To make matters worse, you haven’t told anybody. Maybe you’ve waved off help and given a few rosy status reports: “I’ve got this! Just need one more day!” You’re in deep. You know you’ve spent too much time, but you keep pushing, into nights and weekends. And that’s when you realize that you have to tell people how stuck you are. ...

Today I want to talk about a way I think about debugging: as a story that we tell to ourselves and each other. We often face bugs without much information. Consider an error like this: npm run build The 'compilation' argument must be an instance of Compilation What? This error comes from my work, and changes that I made caused it. I pushed a change to our codebase that removed a flag hiding errors. When the errors were exposed, we had to upgrade dependencies. Along the way, I broke the build, and no one knew it for a while. ...

I’m proud to announce the launch of my digital guide to software debugging, Don’t Stay Stuck: A Debugging Guide for Rising Engineers! I’ve been working on this guide on nights and weekends, and it’s the distillation of a decade of debugging triumph and tragedy. Product Pitch Have you ever been stuck on a tough bug and felt you had no path forward? You’ve tried everything you can imagine, and nothing is working? And then: a sharp engineer drops into the session, asks a few questions, and fixes the bug almost immediately! What is this superpower? ...

“I’m still getting this random 404.” Want to sound pro? Banish “random” from your software engineering vocabulary. Considering the Modern Usage “Random” has a modern usage; let’s consider it. Take this example: “I got a random bill from my dentist.” We hear: “This surprising thing, a bill from my dentist, happened.” We get it. It works. So what’s my issue? Merriam-Webster defines “random” as “lacking a definite plan, purpose, or pattern.” And so, this usage is incorrect, because the bill isn’t random: someone at the dentist’s office sent it to you because they believe you owe money. ...

This is a response to “Don’t Guess” from the excellent “The Best Programmers I Know” by Matthias Endler. My goal is to crystallize my understanding of this trait. “In the face of ambiguity, refuse the temptation to guess.” –The Zen of Python, Tim Peters Guessing is defined as “form[ing] an opinion of from little or no evidence.” As a programmer, it’s tempting to guess while debugging. We might say: “Hey, I wonder if this is happening in GamePlanSyncer? That sure causes a lot of bugs”, while nowhere near the corresponding code. ...

If something in your software is confusing to a customer, it is confusing. It is! There is something about it, that you might not see, that doesn’t make sense to a nonzero number of your customers. Stop trying to outsmart the bug report and consider it. Will you encounter a few outlier customers who are hard to please? A few more who struggle with what seem like obvious interfaces? Yes and yes. ...

My definition of “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. ...

If you’ve ever watched me debug, you might think I’m moving slowly. That’s because I try hard to find every marker on the debugging trail. I believe this is one of the most valuable skills in debugging. What’s a Marker? Let’s say our debugging session is a trail through the forest. ‘O’ is where we are, and ‘X’ is the summit of a mountain. At ‘O’, we know little. At ‘X’, we understand the bug and we’ve fixed it. ...

We spent the time writing tests, and yet, a bug survived. Should we just stop writing tests? No, but we should maybe write better tests, and think about them differently. In this post, I’d like to explain a mental model I have that helps me write and maintain tests: thinking of bugs, and the tests that cover them, in classes. Bugs and Tests in Classes Every test has limitations. Unit tests miss the big picture, end-to-end (E2E) tests miss the details. Rather than chasing the impossible, that the test suite catches all bugs, I’ve found it’s preferable to think about bugs and tests in classes, like the classifications of the animal kingdom. ...