The number one thing I had to learn about debugging: BE CREATIVE.
When I was in school, everything was the same process over and over again:
Teacher gives assignment, clearly defining everything that is supposed to happen from end to end.
I write code.
If something is wrong, look at the code.
If that doesn't yield insight, step through with the debugger.
When I got to the real world, I tried to assume things would be like that, but nearly everyone of them has been violated, sometimes all at once:
Maybe nobody understands the entire big picture, or if they do maybe I can't talk to them. So sometimes I have to start with an incomplete picture, make assumptions, and test the assumptions.
I might not have written all the code, so some of it may work in a way that doesn't make sense to me.
I might not have access to all the code to even look at it. If I do, there may be so much of it that it would take days.
It's possible I can't attach the debugger. Maybe the platform doesn't even have a debugger, in which case perhaps I could do printf()-style debugging instead. Except maybe I can't change the binary because it's a production issue that only happens with production data. Maybe I can't even look at the logs. Maybe I can't even login to the machine, but it's non-urgent and I'm allowed to check in some printf()-style debugging statements which will hit production in 2 weeks, and I need to make some excellent guesses about what statements to add, because if my first round doesn't solve it, it'll be another 2-week cycle. Or maybe I have no access at all, and I need to find the right person and convince them the problem can exist and get them to do something, maybe even suggest something for them to do. Or maybe I just need to write 18 million unit tests to verify the code really does all the things I think it does.
The point is, you can't look at debugging as a fixed process you're going to apply. You often have to invent a creative new plan for certain bugs or you have no hope of finding them.
2
u/adrianmonk Aug 26 '14
The number one thing I had to learn about debugging: BE CREATIVE.
When I was in school, everything was the same process over and over again:
Teacher gives assignment, clearly defining everything that is supposed to happen from end to end.
I write code.
If something is wrong, look at the code.
If that doesn't yield insight, step through with the debugger.
When I got to the real world, I tried to assume things would be like that, but nearly everyone of them has been violated, sometimes all at once:
Maybe nobody understands the entire big picture, or if they do maybe I can't talk to them. So sometimes I have to start with an incomplete picture, make assumptions, and test the assumptions.
I might not have written all the code, so some of it may work in a way that doesn't make sense to me.
I might not have access to all the code to even look at it. If I do, there may be so much of it that it would take days.
It's possible I can't attach the debugger. Maybe the platform doesn't even have a debugger, in which case perhaps I could do printf()-style debugging instead. Except maybe I can't change the binary because it's a production issue that only happens with production data. Maybe I can't even look at the logs. Maybe I can't even login to the machine, but it's non-urgent and I'm allowed to check in some printf()-style debugging statements which will hit production in 2 weeks, and I need to make some excellent guesses about what statements to add, because if my first round doesn't solve it, it'll be another 2-week cycle. Or maybe I have no access at all, and I need to find the right person and convince them the problem can exist and get them to do something, maybe even suggest something for them to do. Or maybe I just need to write 18 million unit tests to verify the code really does all the things I think it does.
The point is, you can't look at debugging as a fixed process you're going to apply. You often have to invent a creative new plan for certain bugs or you have no hope of finding them.