<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Debugging on rjrowland</title><link>https://rjrowland.com/tags/debugging/</link><description>Recent content in Debugging on rjrowland</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Sun, 26 Jul 2026 09:00:00 -0500</lastBuildDate><atom:link href="https://rjrowland.com/tags/debugging/index.xml" rel="self" type="application/rss+xml"/><item><title>Hypothesis-Driven Debugging</title><link>https://rjrowland.com/posts/engineering-practices-hypothesis-driven-debugging/</link><pubDate>Sun, 26 Jul 2026 09:00:00 -0500</pubDate><guid>https://rjrowland.com/posts/engineering-practices-hypothesis-driven-debugging/</guid><description>&lt;p&gt;Debugging by coincidence is making changes until the symptom disappears. The fix &amp;ldquo;works&amp;rdquo; in the sense that the error message goes away. Nobody knows the root cause. Two months later the same bug resurfaces in a different shape, and nobody knows why, because nobody ever understood why the first time.&lt;/p&gt;
&lt;p&gt;Form a falsifiable hypothesis before you touch code instead: &amp;ldquo;I believe the bug is in X because Y. If I&amp;rsquo;m right, evidence Z should be there. If I&amp;rsquo;m wrong, evidence W should be there instead.&amp;rdquo; It&amp;rsquo;s the scientific method applied to debugging, and most engineers skip it in favor of &amp;ldquo;let me try this and see.&amp;rdquo;&lt;/p&gt;</description></item></channel></rss>