How Rock Climbing Made Me a Better Developer

The process of levering my way up a boulder is strikingly similar to the process of writing features or fixing a bug. Applying lessons learned by climbing allowed me to write higher quality code.

Whether or not I am able to climb a particular ridge or feature of a boulder or cliff elicits no response from the granite face. This may or may not be due to the fact that rocks are not alive. Likewise, a codebase that existed before I even learned to code is unconcerned by my frustration with its poor architecture. This is due to the fact that it is a codebase. I cannot erase past commits any more than I can make a hold on a boulder problem one foot closer to me. Holds may be tiny and sharp or even nonexistant. Code may be old and arcane. It may be tightly coupled and rigid and inflexible. Classes may be doing two or three or even twenty things. The code and rock already exist. Despite my ability to change the code or ascend the route, I cannot change the fact that it is already there.

Expectations lead to frustration

Most climbers are in constant competition with themselves. Naturally, the problem I did when starting out is now trivial, and climbers seek climbs with ever smaller, sharper holds with bigger moves on more overhanging rock higher and higher off the ground. Pushing ever upwards in difficulty is natural in sport.

So, when I attempt a measly "V1" boulder problem that sends me flopping down to the ground time and time again, it is incredibly frustrating. "This climb should be easy! I am stronger than this. I should be able to do this!". For most athletes, this isn't an uncommon phenomenon. Sprint intervals that were completed last week should be completed this week, and more easily, too!

So, too, when programming, a bug is encountered. Code relies on a library that should have been updated years ago *Cough* Angular 1.2.25 *Cough*. Frustration sets in. "Things shouldn't be this way." "Fuck this shit code and fuck the developer who wrote it." "Ugh, nobody even uses this part of the product. I don't understand why I have to deal with this shitty Angular app."

In this age of fast-paced JS evolution, Angular 1.2.25 is downright neolithic. I much prefer the niceties of Vue.js. Angular was the framework that cracked the door open for these new kids, though. It aged relatively well, too. John Papa's Angular styleguide established some quality best practices for Angular devs and made it fairly pleasurable to code in. As perhaps the most offensive counterpoint, I work on a Rails 4.2 app with not 1, but 7 angular 1.2.25 applications contained within it. NONE of them follow JP's styleguide. In fact, there is one ng-app in particular that is all contained in a single file. The app, config, services, custom directives, and the controller are all written, with $scope littered throughout, in one. single. file.

Let me make this worse for you. None of the bindable members are up top. The controller is a callback, not a named function. There are over 80 variables and 72 controller functions and none of them are organized alphabetically or logically. It is impossible to know what the app does without reading the entirety of the file. Oh, yeah... the file is just over one thousand and six hundred lines long. When I say, "fuck this shitty angular app", I have a right to. It is undeniably the most grotesue, tortuous, shit code written by a shit developer I have ever laid my eyes upon. But, I still faithfully open the files every day and refactor and make changes and parse poorly written code. Why? Because:

Code is never the real source of frustration. Expectations are. Rock is never the real source of anger. Expectations are. Developers and climbers externalize our desire to fix the bug or climb the problem by expressing frustration with the situation. If I were to attempt to climb Midnight Lightning, a famous V8 in Yosemite, and failed many times, I would not be frustrated. I am nowhere near good enough to climb it. It is a testpiece that has struck down many a professional climber. My inability to ascend it does not anger me when there is no expectation of success or ease.

Frustration prevents progress

Here, I encounter the real issue with expectations: They prevent progress. Anger is temporary madness. It blinds me to the real solution. I hammer away, trying to the same moves on the rock or blindly tossing headers in the client request when CORS errors pop up. I am too frustrated to think clearly about the problem before me.

This happened a few times when climbing. I got mad. I deserved to climb this rock, I thought. How dare I be denied. And then, an old man walked up and styled the problem effortlessly. I was stunned into silence. I was far stronger than he was, physically. It was not my ability preventing me from solving the problem. It was my approach. And suddenly, it clicked.

How do I make progress

By divorcing myself from my expectations. Instead of attempting the same "beta" to climb the boulder, I should rest. Walk up to the boulder and inspect the holds. Pull lightly in various directions. Brush chalk away. Maybe go around back and climb up to look at the problem from above. Try again, and fall. When I fall, ask "Why?". Did my foot pop off because I wasn't pushing hard enough here? Did my hips sag and increase the force on my fingertips drastically? Did I move too quickly and lose my balance? Try again, and again. See what changes when I do this instead. Maybe I will make it further up the route, only to be stopped at a new move.

Instead of trying to code the way I think it should work, I should stop coding. I should breathe and read the documentation. I should start logging things out. Find where in the series of callbacks the error is coming from. Maybe even take time and write code completely unrelated to this code. Come back with fresh eyes and new energy. Sometimes, I will need to ask for help. Sometimes I am not strong enough to climb a route or fastidious enough to dig down to find the true reason a bug keep happening. But that is progress. I have moved further towards the goal by employing honest evaluation of failures and calm inquisition. I have made progress by attempting new things without the expectation that they will succeed immediately or with ease.

Well, duh..

I have not mentioned anything other developers or climbers have not. This is all information that is conveyed fairly often to new developers. I needed rock climbing in order to learn this lesson, though. Sometimes, things just don't click in the problem domain. A lesson sometimes needs a different medium to be understood. Whether that is climbing, or sculpting, or programming matters not. Calm inquisition is a skill that yields great results in many aspects of life. Dealing with other people, with code, with sport, with cooking, etc. etc. This is just another passage dedicated to the lesson. Maybe someone needs the medium of a blog post to learn it?