Over the years I've become more and more convinced that debugging has done a lot to develop my problem solving skills and analytical thinking in general. It's like being a full-time modern times Sherlock Holmes with the crime scene and tools neatly at your disposal.<p>Usually breakpoints and stepping through code solves things pretty easily but some bugs can be real stumpers.<p>Here's some of the tools I tend to use:<p>1. What has changed? What could have caused this bug to appear?<p>2. Verify fundamentals: Is it actually running the code I think it does. If I change something that should change something, does it change? If I break something does it break?<p>3. Verify Input: Make sure it's valid<p>4. Verify output<p>5. Timing issues?<p>6. Slowly remove code "around" bug until it works again<p>7. Or start back at something you know works and add back code until it breaks.<p>8. Break out the functionality into an isolated environment so you can test it separately so you'll know if the problem is within the feature or a side-effect of something else<p>9. If your code makes it too complicated to see and find the bug refactor until it isn't.<p>10. Go to sleep / Go on a walk. Let your subconscious process it<p>and finally, lot's of bugs are made self evident by well structured and refactored code, so don't get too busy working on the symptoms rather than the root cause.
+1 for encouraging the use of logs as a debugging tool - they're often better than a debugger in my opinion [1].<p>Also, bugs aren't only bad - you learn a lot from them too [2].<p>[1] <a href="http://henrikwarne.com/2014/01/01/finding-bugs-debugger-versus-logging/" rel="nofollow">http://henrikwarne.com/2014/01/01/finding-bugs-debugger-vers...</a><p>[2] <a href="http://henrikwarne.com/2012/10/21/4-reasons-why-bugs-are-good-for-you/" rel="nofollow">http://henrikwarne.com/2012/10/21/4-reasons-why-bugs-are-goo...</a>
Writing code is about understanding, also.<p>I've seen developers bang away at a problem for days and not be able to describe how it "works" in a code review. They just tried every crazy thing they could think of until it eventually returned results that looked correct.<p>Don't be that kind of developer. For one, all the other developers are going to make you maintain that code for the rest of your life. Two, never be too proud to ask for help. We can't know how to solve every problem on our own. It's not possible.
Also a couple of tips for the beginning programmer:<p>* You've almost certainly not found a bug in the compiler or libraries or language runtime (somewhat more possible if you're using alpha, beta, or dev versions of something).<p>* Your CPU, memory, or other hardware are not defective.<p>* You are not experiencing cosmic rays flipping bits randomly in your data.<p>* The problem is most likely to be a mistake in your code.<p>I have worked with programmers who are quick to jump at the most unlikely explanations for bugs, and it's a very timewasting way to work.
A quote I have always enjoyed: "Finding your bug is a process of confirming the many things you believe are true, until you find one which is not true." Norman Matloff 2002 <a href="http://heather.cs.ucdavis.edu/~matloff/UnixAndC/CLanguage/Debug.html" rel="nofollow">http://heather.cs.ucdavis.edu/~matloff/UnixAndC/CLanguage/De...</a>
While it's great to see more attention brought to debugging, some of this is just (for lack of a better word) insane. e.g.:<p><i>For searching in space, most programmers have done binary-search with commented code: comment out or bypass half of your codebase. Do that recursively until you nail down where (at which file, which function, which lines) the bug lives.</i><p>No, most programmers actually <i>haven't</i> done this for the simple reason that it's highly unlikely to work: most codebases with half of their functionality removed <i>don't actually function</i>. That this kind of lunacy is being asserted as authoritative is galling enough, but it gets worse:<p><i>When binary search doesn't work, you need more creative approaches. Consider brainstorming to enumerate even the wildest possibilities: for instance, maybe the bug is in some external resource like a library or a remote service; maybe there is version mismatch of libraries; maybe your tool (e.g. IDE) has a problem; maybe it is bit flipping in the hard disk; maybe the date and time library is sensitive to your computer's settings, etc.</i><p>This is advocating debugging by superstition, and it represents toxic thinking. When we have defects in software, we need to be strictly empirical in approach:<p>1. Make observations.<p>2. Think of interesting questions.<p>3. Formulate a hypothesis.<p>4. Develop a testable prediction from the hypothesis.<p>5. Gather data to test the prediction.<p>6. Refine, alter or expand the hypothesis.<p>7. Go to step 4 until defect has been driven to root cause(s)<p>If this sounds familiar, it is because it is the <i>scientific method</i>[1] to which we can credit much of modern knowledge and civilization. As to how this specifically relates to debugging, I touched on this in my recent DockerCon presentation[2][3]. Bringing attention to debugging is terrific -- but advocating superstition as a methodology is anathema to true understanding.<p>[1] <a href="https://en.wikipedia.org/wiki/Scientific_method" rel="nofollow">https://en.wikipedia.org/wiki/Scientific_method</a><p>[2] <a href="https://www.youtube.com/watch?v=sYQ8j02wbCY" rel="nofollow">https://www.youtube.com/watch?v=sYQ8j02wbCY</a><p>[3] <a href="http://www.slideshare.net/bcantrill/running-aground-debugging-docker-in-production" rel="nofollow">http://www.slideshare.net/bcantrill/running-aground-debuggin...</a>
Understanding is the key to everything in software development. In particular, understanding both what you are trying to do and the tools (including language) you are using is necessary for writing code that works.<p>The former is true even if you are doing exploratory development: in that case, you need to understand what has been found so far and what the next iteration is intended to investigate.
I wrote about the relationship between debuggers and logs a while back: <a href="http://www.scott-a-s.com/traces-vs-snapshots/" rel="nofollow">http://www.scott-a-s.com/traces-vs-snapshots/</a>
Debugging can be fun, too.<p>If often found some bugs in a reporting software, that showed the people wrong numbers for years.<p>Or if something needs to be re-implemented, say for performance reasons, you get the algorithms and notice that the old version wasn't only slower but also wrong.<p>When this happens, I start to question if the people really "use" the software in the first place. Or if they just get some wrong sens of safety from it, which calms them, but the underlying system is mostly random and they could simply make up their own numbers.
If debugging is about understanding, then it will be good to use a language that lets you embed the knowledge in the coding. Knowledge should be easier to read from the code leading to a faster understanding, and more bugs are catch by the compiler instead by the end user.<p>This is a great page (with a video) about what I mean<p><a href="http://fsharpforfunandprofit.com/ddd/" rel="nofollow">http://fsharpforfunandprofit.com/ddd/</a>
It's an interesting and helpful article, the downside is that it perpetuates the use of the non-technical language of "bugs" and "debugging." Sure it's accepted jargon, but like most jargon "bug" doesn't really convey much of anything beyond a person's attitude. "Bug" is as unscientific as "weed"...a bug may be the wrong color text in some HTML or as in its origin myth, something preventable with a can of Raid.<p>Fault/Error/Failure provides a better language for talking about systems and their processes. It provides a diversity of solutions from changing the source code, to handling an error, to just letting it crash...the last is impossible to cast as a solution in the nomenclature of bugs.<p>There are times in which there the ambiguity of "bug" matches the necessary ambiguity of the context...just as there are times when describing the sun moving across the sky is useful. But the geocentric cosmological model breaks down when we're interested in predicting the location of Jupiter in the night sky.
Just add asserts to your code. Make an assert for any assumption you make no matter how trivial or unlikely to be broken. And don't disable the assert in release versions.<p>That can, as a very conservative estimate, cut down time spent debugging by 50%.<p>Life is too short to spend it debugging undefined behaviour.
Using logs as a debugging tool is only step one.<p>The second step is using a good tool that helps you make sense of those logs, and includes good debugging information with the logs. A tool like Rollbar (disclaimer: I almost work for Rollbar) makes it super easy to analyze patterns in your errors and logging, find out who experienced the error, and to hear about the bugs before your customer, who may have become used to them.<p>Anecdote from my previous employer: we had a terrible piece of legacy software that regularly had modal pop-ups warning of errors this or that that doubled the amount of time our clients took to do stuff. They were so used to it that instead of reporting the error, they just dismissed them.
Tangential to the topic: The git bisect image has "good" and "bad" backwards, showing the solving of a bug instead of the production of one. I would hope a commit in between would clearly state it contains the bugfix.
While understanding if of course important, sometimes it's possible to just "zen" the bug. After working with the same codebase for long enough I've been able to see behavior and think, "That's probably down in the login handling code..." and then start there. I don't necessarily have to understand the login code, but it's gnarly, and I've seen similar bugs before from it. I'm right more often then I would expect. When the zen fails it's off to the methods mentioned in the article.