Trusting the Scientific Method: Divide and Conquer

That moment when you hit an apparent obscure stack trace:

You're like f***. What does that even mean?

I remember telling myself: "You will have a bunch of these going forward so better get a systematic way of debugging them".

Then I remembered Stuart Halloway's talk: debugging with the Scientific Method. The gist of it being that instead of second guessing, trial errors, to have a logarithmic way of solving a problem.

In the end, even though I know the "how, what and why" the main mistake was I did not write my problem down on a notebook or paper to at least anchor in the brain.

Things that helped:

1. staring at the error message for a while (emotions come and go, so you will hit a moment where you'll get the opportunity to think "reason" about the issue in a more scientific manner.)

2. googling the whole error message and bits of it: This help you better formulate your question.

3. Looking at source code of hiccup.util

Usually, if you can formulate or "google it" the right way you have divided the thing.

From the stack trace a hint is loud and clear hiccup.util line 44 can't handle what I am feeding to it.

Couldn't really understand this, but clearly got the idea, that the thing expected a string or something close :)

So with further divide and conquer the error must come this part of source code:

Once I got to this point, I was confident I solved it in an "inner out" manner, figuring that [:form ] was creating the unnecessary vector.

From this experience, I think the reason why there is not that much blogging on how bugs got solved is that "the bug appears obvious once you've found it and you feel kind of stupid for not figuring out earlier."

This is the nature of the game, embrace it, get better at "Divide and Conquer".

Learn more:
Stuart Halloway on Divide and conquer