Always Forward, Never Straight

“Over.”
“Over.”
“Around.”
“Over.”
I’d come upon a couple of older men hiking up Katahdin’s Chimney Pond Trail and it took me a few seconds to figure out just what was going on. The lead hiker methodically but expertly picked his way up the path, stepping over rocks or walking around them. He narrated as he did so and his partner followed his lead — stepping where he was shown, in the way he was shown.
The lead hiker was attempting to impart, by rote, to his companion, a couple of the very simple and oft-neglected rules of hiking: Whenever possible, conserve energy by keeping an elevational and directional homeostasis; change direction slowly and incrementally and keep your pace smooooooth.
You’ll see three kinds of hikers on the trail: The ones who seem to float on their tippy-toes from the crest of one granite stone to the next; the ones who seem to swim up through the leaf and boulder strewn path like fish gracefully navigating invisible waters; and those who look miserable — jolted with every step as the stutter and drop and climb, gracelessly jarring knees and ankles and backs.
The thought process is: Don’t go up just to come down again eight inches later. Either stay up, keeping your corrections to small inches, or stay down accomplishing the same thing.
This is good hiker hiking hygiene and it’s good software development hygiene as well. It’s associated with Lean Startup concepts but, really, more meta. It’s more about the Tao of developing a piece of software and maintaining your strength for the journey of its implementation.
In hiking, we are talking about eight inches, and to the inexperienced hiker that may seem trivial, especially when the fastest route up seems to be just FORWARD. But imagine the exhaustion you’d feel if you spent six hours stepping up and down an eight-inch step over and over. It’s a waste of movement that does nothing to move you towards your goal and is, in hiking terms, obscenely inefficient. Imagine not just pounding through on a project for a couple of weeks (known to developers as a Death March) but doing that for six months or a year. Imagine the toll that would take.
This thrash approach also has co-morbidity with being lost and being hurt . . . or at least being off trail. Because thrash is distracting and the thrash itself requires recovery that can force hikers trying to keep pace to make poor judgments and get locked into micro-focus. They forget to take the long-view and re-evaluate the larger objective.
They mount a chunk of rock, come down hard on their left foot, come off balance just slightly, pivot right wonkily, over-correct left, hastily place their right foot on the next rock and careen their way up the trail until they are in the woods . . . or miss the trail sign.
This necessitates a major course correction that is the antithesis of efficient and pleasurable. Usually, it necessitates taking off their pack, regrouping, refueling and resolving to do better.
What you want to do is pick a line, sight it, and move through it allowing for small course adjustments. You want to pick a pace that supports both the Sighting, the Adjustments and the Execution of journey by both the body and the mind.
This mindset, this mechanical zen of being able to zoom between the micro and macro in your vision while maintaining a smooth forward rhythm, is one of the things hikers work to achieve and is, for me, one of the very core reasons I hike. It’s an expansive state of mind that leads to a fluidity of movement and a state of harmonious achievement. It’s in this state that you can absorb the beauty around you, notice the shifts in your environment, catch a doe standing 18 feet off the trail, gazing openly at you.
Software development, at its healthiest, requires the same mindset. It is initially slightly more taxing than just muscling your way through, focusing solely on the task at hand, but over the long haul, conserves energy and actually ensures that you reach your intended goal and don’t find yourself at the bottom of a gulch tangled in a raspberry bush. Incremental changes as you move towards a goal that you consistently sight and approach create a path of grace and ease. They keep you in a state of relaxed readiness. You can respond to the needs of the application because you are, and stay, in balance. You are focused on the big goal while staying mechanically conservative.
Banging your way up the trail, towards some goal you’ve conceptualized but haven’t checked in on, while wastefully hauling yourself up and down things that should and could easily be stepped around is, as I like to say, A BAD IDEA.
I like to firmly be in the GOOD IDEA camp when hiking and building software.