Bugs and issues are a reality of life. All life. But, as a programmer, it happens often as a natural part of your job.
Debugging tools are somewhat plentiful and often extremely useful. However, there are occasions where the tools fail you or might even be non-existent.
A debugging axiom is really a principle of thought in such a way that you can attack any debugging scenario with your mind and the code in front of you when you can't rely on your tools.
Let's take a real world example and go over one of the primary debugging axioms I've had to learn over the years: Burn it off.
What's a debug tool really doing?
Say you have a debug tool and you set a breakpoint somewhere in your code and then you execute your code and the code stops at the breakpoint.
What you're really doing here is saying "Hey, everything past this breakpoint doesn't exist. The whole world stops here and nothing else matters".
In a similar fashion, although not exactly the same, burning it off refers to the removal of components, features, code and other factors that help you discern where a bug does not exist.
Yes, that's right, you're removing places a bug cannot live.
Let's take a real world scenario.
The map on the page is slow
That's the bug. The map on the page is slow. That's it. That's the report you've received. Go fix it!
Let's say this page has a header, with some menu items, a footer, with more menu items, and then a content section in the center where content goes. In this particular case, you have a google map. You have an AJAX call that grabs a bunch of JSON which is just a bunch of coordinates. Those coordinates get iterated and planted onto google maps through a google map API and you add nice custom little special marker for each coordinate.
Simplify, simplify, simplify (or burn it off)
Since you've heard that the map on the page is slow, you might be inclined to prove that wrong right away, which is usually the first mistake. Never ever assume the page, as a whole, is doing just fine simply because someone pinpointed the map to you.
Especially if this is coming from a public user reporting a bug. They may perceive the map is slow because the whole page is slow.
In other words, start at the top with no assumptions. Remove the whole map entirely. Don't even load it on the page. Then check to see if the page, itself, is slow. If it's not, awesome, you know that the bug is now most likely with the map.
Add the map back in and check to see if the page is slow. It is? Great, bug confirmed.
Now what?
Keep simplifying. With the map in place, load up just the stubbed map, no ajax calls, no coordinates, no markers or pins, just the plain ol' map.
Still running smooth? Ok so you know it's gotta be in the finer details.
Add the ajax calls back into place and don't do anything with them. Still smooth? Now plot the coordinates of the JSON but don't use any pins. Still smooth? Ok now add the pins with the custom image. Bam, the map is slow.
So now you know it's the pins/markers with the custom image.
Conclusion
That's it! It can be tedious but it's a methodical way of narrowing down a bug by deducing where it does not live. Simplify your code, simplify a page, simplify an app, whatever the case is, simplify or burn off excess items until you get to the items that cause the issue.
I want to emphasize how important it is not to make assumptions just because someone said something and pointed the finger somewhere. I'll cover assumptions as a developer in another video / post.
Top comments (0)