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.
Want to read more? Get the full story over on Medium.
Monica Kosciuk is a student at Launch Academy Philadelphia.