Guessing isn't debugging

Four changes, zero understanding

Picture a bug: article.published? returns false when it's supposed to return true. A common first move is changing something and rerunning it: add a .presence here, swap nil for false there, reorder two lines, sprinkle a puts and squint at the output. Four edits later the bug is still there, or worse, it's "fixed" by accident and nobody knows why, which means it comes back the moment the code changes again.

That's editing code while hoping, and it isn't debugging. It works often enough by luck to feel productive, but it doesn't scale past the simplest bugs, and it teaches nothing about the system underneath.

The actual scientific method, applied to code

Debugging as a discipline borrows directly from experimental science: four concrete steps, done in order.

1. Observe the real behavior: not what the code is assumed to do, what it does, confirmed directly, right now.
2. Form one specific hypothesis: a single, falsifiable guess about the cause, precise enough that it could turn out to be wrong.
3. Design the smallest test: the least work that would prove or disprove that one hypothesis, nothing more.
4. Change one variable at a time: test one thing before touching the next, so a result can be attributed to something specific.

Each step earns the next. Jumping straight to "change something" without observing and hypothesizing first is the four-random-edits pattern above, just with more confidence attached to it.

The running example for this course

Every lesson here works through one real bug in ScratchDebugArticle, a disposable model built fresh for this course, its published? method modeled directly on the illustrative Article#published? from "Rails MVC overview". Someone sets published_at on an article, expecting published? to return true, and it doesn't. Lesson 2 starts there, confirming what happens before guessing why.

Where this course goes

Lesson 2 observes the real, current behavior of the broken call. Lesson 3 turns that observation into one falsifiable hypothesis. Lesson 4 designs the smallest test for it. Lesson 5 covers a second and third hypothesis, one variable at a time. Lesson 6 goes from a confirmed hypothesis to an actual fix. Lesson 7 replays the whole session end to end.

This builds directly on the "Rails console (IRB)" course: every hypothesis here gets tested at the bin/rails console prompt, the exact same tool that course introduced for calling real methods on real objects and reading real return values.