Stepping Away

This is a simple post (actually it’s ramified through multiple edits [can you detect the seams?]) on the efficacy of occasionally stepping away from stumping problems (particularly in regards to programming, but more generally, in regards to any arena of challenges).

I have often experienced the following:

I’m trying to fix a problem or perhaps many embedded problems.  I’ve spent hours debugging, stepping through code, following dead ends, identifying likely problem-nourishing conditions,  et cetera.  Still doesn’t work.  I can point in the problem’s direction, but I can’t pick its seat out of the crowd.  Frustrated, I step away for five minutes, come back to sit at my desk, and solve the problem forthwith.

This illustrates the value of stepping away.

What’s happening here?  Is this magic?  “Sometimes the quantum spin flippety-widgets.”  No.  I’ve made up a pretty good story about what is going on.  I’ll share it with you.

There are different kinds of problems and different kinds of solutions.  Some are more directly achieved by stepping away from in order to approach.

I have found that math and programming share the same spirit.  I think it is a misconception to think that a person must be good at math to be a good programmer (contrary to common expectations).  However, without contradiction, I also think that math and programming, at the level of doing, are merely variations of a single principle.  Doing mathematics involves applying (studied) algorithms (for both the student and the researcher).  Either algorithms of reasoning or algorithms of symbolic manipulation or whatever.  The same is true of programming.  My version of doing either of these activities involves using tools of reasoning to arrive at quantitative (testable) conclusions, often by way of a constantly evolving toolbox of reusable patterns (I mean: our IDE and lisp macros and keyboard shortcuts, discarded code and refactoring tools, are all as much part of the essence of programming as is language {c#, javascript, c, ruby, etc} and design and reasoning patterns {How to Solve It by Polya, An Introduction to the Theory of Numbers Hardy, etc}.  We use these patterns of behavior to arrive at both an understanding of the problem and a working, maintainable, realization of a solution]).

One thing I learned from mathematics is that being good at math, in fact being good at almost any pursuit involving building out complicating logic, involves having a good short term memory (there are exceptions?).  In order to make progress with highly interrelated, self-supporting data and metadata (like the sort involved in real world problems) the data must be kept in easy reach of the reasoning that is using it to bootstrap conclusions that weren’t there before.  Abstraction, for instance, creates new facts through a process of identifying similarities between other facts.  In order to do that, the facts, first of all, must be there.  {TODO: examples <this TODO: is an example>}

our reasoning must perform the function of magrittes canvas in front of a real window

Magritte’s painting is title “The Human Condition” and it depicts (to me), in bon mot fashion (tee-hee, it’s a painting), how my expression of wanting to include examples of how abstraction requires facts is itself an example of abstraction requiring facts.  It also suggests some pretty far out resonances and abstractions to the main thread of thought of this post.  I’d love for readers to comment on which resonances resonate most with them.

Keeping all this data in mind is highly connected to the “zone” or the flow, sought and loved dearly by programmers and all others who’ve experienced it, alike.  To be interrupted when in the zone is often to lose the carefully built house of cards of temporary reasonings stored in short term memory (short term memory is a process not a thing, like RAM).  As previously observed, this data is not only measurements of stuff out there, for instance, it is also internal (meta)reflections on the abstract interrelationships of the data in mind.  So what does this say about stepping away?  Aren’t we disrupting our house of cards of contextual data.  Aren’t we setting ourselves back?

Definitely.  Sometimes this is precisely in the direction of the solution.  Sometimes we’re not only going in the wrong direction, but we’re in the wrong region and any roads we find thereabouts aren’t going to bring us anywhere nearer.  By getting up and walking around, the data we’ve collected will shrivel into dust in the wind.  The longer we stay away from our desk (or whatever, you know what I mean) the more the edges of the previous context will erode (graph theory).

How long you stay away is important.  You don’t want to stay away too long because you’ll lose too much.  You don’t want to stay away for too short a time because you won’t have backed out of the wrong turns you’d already made.  Maybe it’s not even time to step away just yet, sometimes the solution rests just a little further along the way.  Imagine always stepping away just before you abstracted the data away.  It is better to abstract the data than to let it disappear.

It’s an art of the problem solver to know just how long to stay away and when to take that vacation.  You have to have some sort of internal sense of how much of your RAM (that’s a metaphor) is filled up with contextual data, and how quickly it is going away.   It helps to realize something of what is going on internally, in neuronal terms (even if it’s just a simple story with almost no relation to how things actually work):  Little connections are forming between neurons and if they aren’t strengthened repeatedly through being activated in the course of brainwork then eventually they will be so nebulous as to be unreachable (except maybe through hypnosis?  I find it very difficult to believe that the brain can store all information permanently… information explodes exponentially).   Once these little pathways are unreachable you’re forced to approach those aspects of the problem freshly.

I find that there are still meta-reflections stuck around that help me navigate right to the source of the problem.

How can a forest be occluded for all the trees?  Isn’t that just another saying that doesn’t make any sense when you think about it.  If you take away the trees, so goes the forest.  But there is a point to the statement if you consider someone not noticing that there is a forest in front of them because they’ve positioned themselves so close to a couple trees that they can’t see anything beyond them.  The forest was occluded by some of the trees.  Get those trees out of the way.  And even if you’ve never moved a tree before, I’m going to guess that you’ll agree with me when I say that moving oneself is easier than moving a tree (unless you’re stuck in a bear trap, or something, but I still argue that moving yourself would be easier than moving the tree {unless the bear trap is secured to the tree, then, in order to move yourself, you’ll pretty much have to do something with the tree anyway <but I don’t know what to do if it’s secured to a boulder |figure out how to survive on what’s around you|>}]).

PS> By the way, the very next day (today [the day I’m writing this]) I worked on something for 20 minutes, got a coffee, came back, solved it.  Bam.  No fan fair.  I only realized it later.  Then I remembered it again to edit this post.  It happens all the time… (“perhaps you’re setting it up, blind fool!” [“perhaps I take advantage of patterns that work, and work around them])

4 thoughts on “Stepping Away

  1. […] Stepping Away I spoke of there being other resonances to Magritte’s painting in the context of thought […]

  2. […] undifferentiated substrate is the thing being overcome in yoga.  IOW, we have another case of the forest being invisible for a few trees (consider someone not noticing that there is a forest in front of them […]

  3. […] I’ve been enamored of the idea of a hyperdocument for a while now.  Now, I don’t know who all’s reading this, but I can speak for myself and say that while I’m not stupid or blind, I nevertheless never truly reflected on the depth of the idea of a hyperdocument until about 2 years ago.  The idea of a hyperdocument has been around since I was in high school, and I’ve known all the relevant information for a decade, but I hadn’t yet suffered for the problem it solved.  It wasn’t until I’d programmed a lot for many years that I saw.  All program code suffers the same flaw in that none of it can describe nor facilitate it’s own navigation or high level architecture.  Code inevitably becomes a jumble of unnumbered chapters as time removes the details from mind. […]

  4. […] Ability to step away from problems […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s