4 ms·

Debugging is impossibly difficult to teach. It's much closer to "how to solve an escape room" than it is to "how to build X". Debugging requires deep understan

by Swizec 6y ago

Debugging is impossibly difficult to teach. It's much closer to "how to solve an escape room" than it is to "how to build X". Debugging requires deep understanding what you are doing and your system. It's different every time. And while there's a general algorithm you can follow: 1. Guess what's wrong 2. Ask "How would I prove that's wrong?" 3. Try it 4. If bug found, fix, if not go back to 1 How would you teach that other than asking people to go solve a bunch of real world problems in real world systems for a few years?

slibhb 6y ago
> 1. Guess what's wrong 2. Ask "How would I prove that's wrong?" 3. Try it 4. If bug found, fix, if not go back to 1 I think this is exactly right. Teaching 1 is impossible I guess but the general method (it's basically the scientific method in an ideal environment) seems teachable. Come up with a hypothesis of what's wrong, try to prove or disprove the hypothesis.
lainga 6y ago
I might suggest a few of the adventures of Sherlock Holmes.
- prewett 6y ago
  So, having conveniently written a monograph on the exact topic that provides extra information, the extraordinary ability to know exactly which minor features of the situation are contradictory, and access to knowledge unavailable to the reader?
colonwqbang 6y ago
For a system of moderate complexity, there are myriad answers to question (1). A skilled programmer has the intuition to guess the most likely causes. This ranges from the mundane (e.g. recompile everything from scratch) to the occasional almost magical lucky guess which immediately leads to a solution.
Fronzie 6y ago
The one beginners often miss: What output do you expect? Ask this yourself before starting the debugger. Without this, it is very easy to glance over the point where things go funny.
anaerobicover 6y ago
This doesn't seem to be a different problem in kind than teaching people to write programs. How do we do that other than teaching them some mechanics (syntax, how to run the compiler) and then setting them a lot of exercises to gain experience? The same seems to apply to debugging. A student needs to be introduced to the basic concepts and commands, and then practice. Just same as with a writing exercise, the instructor can have specific problems to practice specific techniques.
travisjungroth 6y ago
I think this is the standard algorithm and it's absolutely terrible. People poke at things, which ends up giving a linear search across a possibly huge system. Even if the "guess" is intelligent, it's not like you can trust it. If you actually fully understood the system, you would know what's wrong and you wouldn't be debugging. Do a bisect instead. The complexity is O(log n). It's probably slower than if you guess right on the very first time, but that's less important. Debugging time is dominated by the worst cases. 1. Do something you're 90% sure will work that's on the path towards your actual goal. 2. If it works, move forward in complexity towards your actual goal. Else, move halfway back to the last working thing. 3. When you've trapped the bug between working and non-working to the point that you understand it, stop. "The weather data isn't getting logged to the text files. Can I ping the weather servers? Yes. Can I do a get on the report endpoint? Yes. Can I append to a text file? Yes. Can I append a line to the weather log file? No. Ok, that narrows it a lot." The real point of this is that you should spend most of your time with working code, not non-working code. You methodically increment the difficulty of tasks. This is a much more pleasant experience than fucking around with code that just won't work and you don't know why. Most importantly, it completely avoids all those times you wasted hours chasing a bug because of a tiny assumption. It's sorta like TDD but without the massive test writing overhead. A modification for the disciplined: give yourself one (1) free pass at just taking a stab at the answer. This saves time on easy fixes. "Oh, it must have been that the country setting in the config file is off." Give it a single check. And if it's not that, go back to the slow and steady mode. Cause you don't understand the system as well as you thought.
- Swizec 6y ago
  Your algorithm is for creating programs or adding new features. Not reslly for debugging already broken stuff. I would agree that hoing from less to more complexity is a great heuristic for making those guesses on what to check.
  - travisjungroth 6y ago
    This is normally described as a way to write code, but it works for debugging if you can modify the system or at least give arbitrary inputs. It doesn’t really apply to “read only” debugging.
ianmcgowan 6y ago
It feels like there are basic heuristics that too often people either don't know or forget to apply. I recommend http://debuggingrules.com/ http://debuggingrules.com/ - it's a good book that lays out some rules that have always helped me. When people come to me for help debugging something, invariably they've skipped some of these concepts, and applying them usually gets to the bottom of things faster than randomly changing things (which seems to be a common, but ineffective, way to debug a problem). UNDERSTAND THE SYSTEM MAKE IT FAIL QUIT THINKING AND LOOK DIVIDE AND CONQUER CHANGE ONE THING AT A TIME KEEP AN AUDIT TRAIL CHECK THE PLUG GET A FRESH VIEW IF YOU DIDN’T FIX IT, IT AIN’T FIXED
8note 6y ago
There's also: 1. Pick a spot in the code 2. Figure out what you expect the state to be there 3. Check and see that the actual state matches You can kinda binary search your way to the location of a bug by looking in different places
tiborsaas 6y ago
My general approach is simply to ask: what changed? This assumes that I'm working with an already working system, but if I'm implementing a new feature, debugging is easier since I have more flexibility to explore alternative approaches.

by Swizec 6y ago

slibhb 6y ago

> 1. Guess what's wrong 2. Ask "How would I prove that's wrong?" 3. Try it 4. If bug found, fix, if not go back to 1 I think this is exactly right. Teaching 1 is impossible I guess but the general method (it's basically the scientific method in an ideal environment) seems teachable. Come up with a hypothesis of what's wrong, try to prove or disprove the hypothesis.

lainga 6y ago

I might suggest a few of the adventures of Sherlock Holmes.

prewett 6y ago
So, having conveniently written a monograph on the exact topic that provides extra information, the extraordinary ability to know exactly which minor features of the situation are contradictory, and access to knowledge unavailable to the reader?

colonwqbang 6y ago

For a system of moderate complexity, there are myriad answers to question (1). A skilled programmer has the intuition to guess the most likely causes. This ranges from the mundane (e.g. recompile everything from scratch) to the occasional almost magical lucky guess which immediately leads to a solution.

Fronzie 6y ago

The one beginners often miss: What output do you expect? Ask this yourself before starting the debugger. Without this, it is very easy to glance over the point where things go funny.

anaerobicover 6y ago

This doesn't seem to be a different problem in kind than teaching people to write programs. How do we do that other than teaching them some mechanics (syntax, how to run the compiler) and then setting them a lot of exercises to gain experience? The same seems to apply to debugging. A student needs to be introduced to the basic concepts and commands, and then practice. Just same as with a writing exercise, the instructor can have specific problems to practice specific techniques.

travisjungroth 6y ago

I think this is the standard algorithm and it's absolutely terrible. People poke at things, which ends up giving a linear search across a possibly huge system. Even if the "guess" is intelligent, it's not like you can trust it. If you actually fully understood the system, you would know what's wrong and you wouldn't be debugging. Do a bisect instead. The complexity is O(log n). It's probably slower than if you guess right on the very first time, but that's less important. Debugging time is dominated by the worst cases. 1. Do something you're 90% sure will work that's on the path towards your actual goal. 2. If it works, move forward in complexity towards your actual goal. Else, move halfway back to the last working thing. 3. When you've trapped the bug between working and non-working to the point that you understand it, stop. "The weather data isn't getting logged to the text files. Can I ping the weather servers? Yes. Can I do a get on the report endpoint? Yes. Can I append to a text file? Yes. Can I append a line to the weather log file? No. Ok, that narrows it a lot." The real point of this is that you should spend most of your time with working code, not non-working code. You methodically increment the difficulty of tasks. This is a much more pleasant experience than fucking around with code that just won't work and you don't know why. Most importantly, it completely avoids all those times you wasted hours chasing a bug because of a tiny assumption. It's sorta like TDD but without the massive test writing overhead. A modification for the disciplined: give yourself one (1) free pass at just taking a stab at the answer. This saves time on easy fixes. "Oh, it must have been that the country setting in the config file is off." Give it a single check. And if it's not that, go back to the slow and steady mode. Cause you don't understand the system as well as you thought.

Swizec 6y ago
Your algorithm is for creating programs or adding new features. Not reslly for debugging already broken stuff. I would agree that hoing from less to more complexity is a great heuristic for making those guesses on what to check.
- travisjungroth 6y ago
  This is normally described as a way to write code, but it works for debugging if you can modify the system or at least give arbitrary inputs. It doesn’t really apply to “read only” debugging.

ianmcgowan 6y ago

It feels like there are basic heuristics that too often people either don't know or forget to apply. I recommend http://debuggingrules.com/ http://debuggingrules.com/ - it's a good book that lays out some rules that have always helped me. When people come to me for help debugging something, invariably they've skipped some of these concepts, and applying them usually gets to the bottom of things faster than randomly changing things (which seems to be a common, but ineffective, way to debug a problem). UNDERSTAND THE SYSTEM MAKE IT FAIL QUIT THINKING AND LOOK DIVIDE AND CONQUER CHANGE ONE THING AT A TIME KEEP AN AUDIT TRAIL CHECK THE PLUG GET A FRESH VIEW IF YOU DIDN’T FIX IT, IT AIN’T FIXED

8note 6y ago

There's also: 1. Pick a spot in the code 2. Figure out what you expect the state to be there 3. Check and see that the actual state matches You can kinda binary search your way to the location of a bug by looking in different places

tiborsaas 6y ago

My general approach is simply to ask: what changed? This assumes that I'm working with an already working system, but if I'm implementing a new feature, debugging is easier since I have more flexibility to explore alternative approaches.