DEBUG THE SOUP

June 7th, 2021

In programming there’s a grave mistake that’s quite easy to make.  It happens when the program, instead of having an end, loops back on itself.  This is called an infinite loop and it’ll heat up your CPU faster than a microwave.  In all other parts of programming, debugging takes place through the use of print statements, or logging values to a console.  It’s from these local values that a coder can make sense of where the program is going, and where it needs to go.  But when an infinite loop occurs, any print statements happen like an infinite stutter and the console is quickly backed up with thousands of repeating statements within a second or two, and it doesn’t stop until the environment in which the program is running is killed outright.  This inconvenient detail can make it quite challenging to debug an infinite loop, because often it’s not possible to examine the problem without activating the problem.  The infinite loop is a bit like the universe telling you that what you want can’t be done, and the only reasonable way to react is to rebel.

Many efforts result in infinite loop - like outcomes: where our effort seems to have no effect on the reality we are trying to impact.  We change this variable, we rewrite the function, but still the same dead end swirl of “not working”.

One way to zero in on the issue of an infinite loops is to start subtracting bits of code.  Taking out chunks eventually results in no infinite loop which signals that the missing chunk is the problem.

We can do the same with our efforts in other areas of life.  We try to do so much, putting everything together at the same time, but the melange of variables quickly obscures exactly what is having an effect, if any.  This is the virtue of starting small and trying to make a minimum viable effort have a minimum observable impact.  Once the correlation is strong enough to safely imply causation, then a new dimension can be added to see what the new effect might come about.

With an infinite loop, that subtracted chunk of code - which is clearly the culprit - can be whittled down even smaller by subtracting smaller and smaller chunks of the problem until the issue has been narrowed down as much as possible.  Such a problem is not solved by reasoning but by a process of elimination.  

Process by elimination is of course a form of reasoning, but it’s a tool we rarely use in view of our efforts.  We almost always reason forward: if I do this, then that will happen.  But our idea of what to do is usually multifaceted with many moving parts and variables.  Rarely do we simplify to a single action for the purpose of achieving a singular result.  We want it all at once, so we try to do it all at once, but the effect is muddled.  But by using a process of elimination, like removing most food types from a diet in order to introduce each one at a time to notice their result, we can see what effect actually correlates to which input.