# How to Debug Anything

DevFeed: [How to Debug Anything](<https://devfeed.tech/articles/how-to-debug-anything-19063.md>)

Original publisher: [Read original article](<https://httptoolkit.com/blog/how-to-debug-anything/>)

Author: HTTP Toolkit; Tim Perry

Published: 2019-12-02T15:00:00Z

Content type: tutorial

Language: en

Sources: [HTTP Toolkit](<https://devfeed.tech/sources/http-toolkit.md>)

Topics: [debugging](<https://devfeed.tech/topics/debugging.md>), [Development](<https://devfeed.tech/topics/development.md>), [Software Engineering](<https://devfeed.tech/topics/software-engineering.md>)

Tags: [debug](<https://devfeed.tech/tags/debug.md>), [debugging](<https://devfeed.tech/tags/debugging.md>), [developers](<https://devfeed.tech/tags/developers.md>), [how-to](<https://devfeed.tech/tags/how-to.md>)

## AI overview

A practical guide to debugging software methodically. It recommends narrowing a problem to a sufficiently small area, using tests to separate working and broken parts, and taking careful notes while investigating mismatches between expected and actual behavior.

## Source excerpt

Debugging is an important skill for any developer. Arguably the most important skill, if you consider debugging in the general sense: exploring a system, explaining its behaviour, and working out how to change it. Nonetheless, most of us are bad at it. We don't methodically work through a process. Instead, we guess wildly, sprinkle logging at random and change things blindly, until the problem disappears. Fortunately, we can improve! I've been talking to a whole range of brilliant developers about their top debugging advice to put together a superguide to debugging, drawn from all their years of expertise, and my own software development experiences. So, without further ado: how do I debug? Narrow down your problem In most debugging situations, you start with a mismatch between what you expect and reality. The user clicked a link to our website. I expected it to load for them, but it never did. Server A sent a request to server B. I expected it to receive a result within 100ms, but server B took 20 seconds. The customer entered their credit card details correctly. I expected them to be charged, but they never were. To be able to fix a problem, we need to understand it sufficiently that there's a clear & acceptable fix available. Note that 'sufficient' is contextual: sometimes "server B is broken, we can just reset it" is fine, sometimes "server B has disk corruption caused by our pattern of IO usage" is just the beginning. Let's look at how to isolate the location of the problem first, and we'll explore how to explain it (and fix it) later. Narrow down the area where things can be going wrong: it's not working here, so is everything correct at x earlier point? Yes? How about y point between here and x? - Nicole Williams Your first step is to focus your debugging down to a sufficiently small area that you can start thinking about fixes. In effect, you're running tests to separate the parts of your system that are working correctly from the parts that aren't, repeated