> > Call your shot. Before you run code, predict out loud exactly what will happen.
> M, okay, but what exactly do you mean by that?
I frequently do a variant of this, although not always out loud. One way to debug a problem is to randomly vary various bits of the program until the problem no longer appears. Another way to debug a problem is to use the scientific method: develop hypotheses, then test those hypotheses with an experiment. I think he's saying to develop hypotheses, and then run code to test them.
I routinely use the "scientific method" to debug. But usually by then it's too late: the code is too hard to reason about so I have to treat it like a blackbox and "observe" its "responses" to the "stimuli" I'm changing.
> M, okay, but what exactly do you mean by that?
I frequently do a variant of this, although not always out loud. One way to debug a problem is to randomly vary various bits of the program until the problem no longer appears. Another way to debug a problem is to use the scientific method: develop hypotheses, then test those hypotheses with an experiment. I think he's saying to develop hypotheses, and then run code to test them.
edit: https://news.ycombinator.com/item?id=11859090