Recently, I’ve been reading about a structured approach taught in “Why Programs Fail: A Guide to Systematic Debugging” by Andreas Zeller.
Zeller suggests debugging using the scientific method, where we analyze what we know, propose a hypothesis about where the bug might be (or where it might not be), then devise an experiment that tests our hypothesis. As we run more and more experiments, we gain information that helps us pinpoint where the bug originates from.
I’ve been trying this at work and I think it’s pretty effective!
For others, there is a free MIT reading that summarizes this approach:
Nice overview. Personally, a huge shortcut is to answer the question 'when did the problem appear, and what changes right before that'.
Earlier in my career, I had an incident where I published multiple changes in a complex environment, and things broke. I reverted the PRs I thought are relevant to the problem, and then spend days debugging it... (before finally reverting ALL of them).
Now - when the system behaves strangely, or there is a complex bug, and there is a code change write before it - the first thing I do, is revert the change. Even if it'll cause conflicts and headache, and even if I'm 99% sure it's not releated. Then I can start to debug :)
Great tips! Belief is a big one. I’ve had many cases where walking someone through a process showed them that it was possible. Once they saw it was possible, they knew they could do it themselves.
Giving up easily is a problem. The more you dig, the more you will be able to find out things. Even if those things aren't directly related to the actual problem.
Many times eliminating what's not related to a problem, helps scope down where the root cause of the issue(s) might be.
Amazing post! Subscribed to your newsletter.
One of the biggest blockers is thinking you can't solve a problem.
It's not at your "level".
Instead, have the confidence you can solve any problems with enough time and effective strategy.
Thank you, Tiger!
Yea it is one of the biggest reasons I have seen folks not succeed.
Great post!
Recently, I’ve been reading about a structured approach taught in “Why Programs Fail: A Guide to Systematic Debugging” by Andreas Zeller.
Zeller suggests debugging using the scientific method, where we analyze what we know, propose a hypothesis about where the bug might be (or where it might not be), then devise an experiment that tests our hypothesis. As we run more and more experiments, we gain information that helps us pinpoint where the bug originates from.
I’ve been trying this at work and I think it’s pretty effective!
For others, there is a free MIT reading that summarizes this approach:
https://web.mit.edu/6.031/www/sp22/classes/13-debugging/
Thank you. Also thanks for the book recommendation and sharing the gist. I didn't get a change to check it out yet, I will.
Nice overview. Personally, a huge shortcut is to answer the question 'when did the problem appear, and what changes right before that'.
Earlier in my career, I had an incident where I published multiple changes in a complex environment, and things broke. I reverted the PRs I thought are relevant to the problem, and then spend days debugging it... (before finally reverting ALL of them).
Now - when the system behaves strangely, or there is a complex bug, and there is a code change write before it - the first thing I do, is revert the change. Even if it'll cause conflicts and headache, and even if I'm 99% sure it's not releated. Then I can start to debug :)
Yea rolling back the last change is always a good bet especially the issue started happening after the release.
For us we build binaries so roll back is not necessarily undoing the PR and dealing with merges.
Another thing we do is gate features behind a flag to make it easy to toggle a change off.
Great tips! Belief is a big one. I’ve had many cases where walking someone through a process showed them that it was possible. Once they saw it was possible, they knew they could do it themselves.
Yea some many times I have had senior engineers feel self-doubt which would slow them down!
Giving up easily is a problem. The more you dig, the more you will be able to find out things. Even if those things aren't directly related to the actual problem.
Many times eliminating what's not related to a problem, helps scope down where the root cause of the issue(s) might be.