Getting past the crux in climbing and in coding

In climbing, a crux is the most difficult or most dangerous section of a route. The grade of the route is based on the difficulty of the crux. Some routes have a really difficult crux and the rest of the route is easy sailing from there. Others may have several cruces. And still others may have a consistent difficulty level all the way through with no crux.

I’m finding many similarities in how to get past the crux in both climbing and coding. If you’re just watching someone climb (or live code), you’re not going to get better at it yourself. You’ll have ideas on how to execute the problem (route) better in your mind, but you won’t actually have that muscle memory or specific balance required to run the route yourself unless you actually run the route yourself. Coding is the same way. You won’t be able to familiarize yourself with the steps required to go from start to working product unless you sit yourself down and code through the NoMethodErrors, pry into the non-working code, and see what it’s doing versus what you think it’s doing. You can bring yourself to stackoverflow and lookup people’s answers to questions, but unless you try them out yourself and see what works for your specific code, it’s going to remain in its current state. I try to pry into what I think is even working code to see what it’s doing just to make sure.

You execute unit tests in coding just as you run tests on a climbing problem to see whether your idea for a move will fail or succeed. Will you fall off that heel hook or successfully push yourself up to the next rock on the route? The more you test your move, the better balance and confidence you’ll have in pulling off that move when you’re climbing the whole route. You’re going to have confidence in any code you’re refactoring if you write good tests for it.

I’m also finding similarities in the process of working together in climbing and in coding. One person may have a better idea on how best to get past a route’s crux whereas, on another crux of the same route, someone else might have an easier time and a clearer solution. One person might code a cleaner looking function than another, but later on down in the path to a working product they may have a harder time implementing another function that someone else flew through. Sharing ideas and helping each other get a better handle on the cruces makes us better coders.

I’m going to be starting Week Three of Launch Academy’s immersive in-person program, but it feels like it’s been two months with all of the new techniques, languages, and frameworks that I’ve learned. I thought I’d combine my two passions for this update on the journey.