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.

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.

In many group debugging sessions I’ve joined, a major technique being deployed is something I call “Try This” debugging. In this post, I’d like to talk about this anti-pattern, and consider a better way.

I saw a meme this week: a person debugging code, “My code doesn’t work. Let’s change nothing and run it again.”

This is something that I’ve done. It seems pointless. But that’s not quite correct.

This is a list of all the best debugging tips I’ve picked up over the years. Some of these might seem obvious, yet we forget them when it counts. Debugging is a skill. You have to bring every tool you have to the job.

Perhaps you’re familiar with this scenario: you’re debugging and stuck. You’ve Googled, read some blog posts and docs. You return to your search engine, type some characters, and then something strange happens: the search engine autocompletes your question, and the results are all purple because they have been visited by you. I’ve come to recognize this moment as always a symptom of a broken mental model.

When printing a JavaScript value to the console, I suggest using an object literal over the raw value.

Bugs are part of software, and so is bug reporting. Reporting well is a necessary skill in an ever-growing number of job titles. In this post, I’d like to explain how to write a perfect bug report.

Imagine you’re debugging, and you’re stuck. I have a technique that’s going to help. Think of an action you might take. Predict what will happen when you take that action. Take the action. Check if you were right or wrong, consider that information, and repeat.

Some code is broken, and you can’t figure out why. Maybe there are a lot of changes to consider, and identifying that breaking change seems impossible. Or, maybe you’re curious about how things generally break in your organization. The tool you need is git-bisect.

A common anti-pattern on sites where code is discussed, such as Slack, Stack Overflow, GitHub Issues, etc., is to post a screenshot of code when asking for help. This technique has many problems, and there’s almost always a better alternative.

A stumbling block for many people when debugging is reading the stack trace. Today I’d like to discuss this important skill.

I remember the first bug that I shipped to production. I was upset that I’d broken something and was anxious to fix it. But I noticed something curious: the calm demeanor of a senior mentor helping me. They refused to meet my intensity. While the world burned, they wanted to instead discuss the bug and its relative importance.

You were stuck, and now you aren’t. Congratulations! Before you move on, it’s vital to stop and learn from it. It’s the best way I know to get better and spare your mind for increasingly harder problems.

We’ve all seen this: a frustrated coworker hunched over a computer after hours, flailing alone against some impossible bug. Go home, coworker. Don’t stay stuck.

Here’s a trick that that has helped me as a programmer: before doing anything major, like killing a process, stop and count to ten.

When I create Agile bug tickets, I don’t add Agile story points. In this post, I’d like to explain this preference via two arguments: pointing bugs creates backward incentives, and bugs are surprisingly difficult to point.