During nearly every software project or coding effort I have ever undertaken there has usually been at least one moment of ‘downtime’ – an interminable period during which the machine seemingly acts in what appears to be complete defiance of the behavior desired. No matter what I would try to do in order to accomplish my goal, I would be met only with a maddening error message. As my conscious mind would run through a host of possible causes and solutions, I felt as if the deus ex machina that had so often inspired me had been replaced by a diabolus ex machina, cackling invisibly behind the beveled interface, its cursor aptly named.
Getting the error message to change – somehow – would often be my first sign of salvation… after all, if I could identify the cause of the error I could potentially solve it. But it often seemed nothing would work to even change the error at all in a productive way. The descent into madness (or at least, frustrated anger) seemed to accelerate. Depending on the severity of the situation and the urgency with which I needed to accomplish the original goal, I might employ a wide array of both secular and spiritual solutions to somehow lift the curse. These would often begin with a quiet moment in which I would try to think through the problem logically, and sometimes that worked – but not often. An appeal for divine intervention via Google search might serve to validate my quandary… surely I was not alone, and someone else had encountered the same error message or condition?
My despair, if not lifted, could only deepen. If a ready answer had not presented itself by this time, frustration would likely be mounting. As emotion and cold reasoning fought for floor space in my brain, print and/or online manuals were soon consulted amidst alternating deep breathing and exasperated sighs. Even a desperate ‘laying on of hands’ on the machine itself would be attempted, sometimes providing the necessary tribute, but just as often being of no avail. Here at the precipice – this dreaded point of hopelessness when an earnest IT staff member would kindly (but blindly) recommend thrice rebooting – is where one finds the true measure of their character. Most often, looking inward would reveal the source of the perceived error, the fault lying not within the program but within the programmer. Ninety-nine times out of one hundred, it is not the machine whose behavior is undesirable to the programmer but the programmer whose keystrokes are undesirable to the machine.
Getting some distance and giving my mind some downtime (whether through a walk around the block, some quiet moments with a loved one, or a blessed nap), would often be my surest way to gain the altitude necessary to overcome the procedural hurdle confounding my logical mind. Certainly, machines fail, unforeseen compatibility errors present themselves, corruptions occur, and hard drives crash miserably. However, these events are comparatively rare in comparison to the self-made brick walls we all erect as we craft software. In these moments of greatest frustration, a programmer often makes the greatest cognitive leaps through acknowledgement and recognition of the fact that it is as much the machine that conditions the programmer’s behavior (for good or ill) as it is the programmer creating conditions for the machine.
Isn’t it telling that refreshing one’s mind by distraction, fun, rest and companionship is often the best route towards better problem-solving and higher quality work? Just as with any athlete, diligent work and training is essential, but occasionally it is the intentional avoidance of work and training that helps us achieve the best results.
As often as not, it seems downtime is the best cure for downtime.
