Mastery over success

Can self-imposed rules make you a better programmer? My thoughts based on deliberately practicing your skills in order to improve.

Posted by Eddo on September 21, 2017

Each different profession has its own rules and regulations, some are mainly there to provide guidance, and others are imposing. When I recently came across this article about rules in climbing to get better, I did notice a similarity with a creative profession such as writing software (i.e. programming).

Although not all rules mentioned in the article can be directly translated to the software writing world, the overall idea behind mastery over success seems to be deliberate practice.


Dilbert, by Scott Adams

Deliberate practice is usually mentioned together with the 10.000 hours of practice rule in order to get really good at something. However, you don’t need to be spending 10.000 hours in order to apply the principles behind and improve your skills. Just practicing deliberately will ensure that you improve the skill. The concept is usually mentioned in conjunction with flow, or being in the zone. And indeed, there is a relation between the two concepts:

Deliberate practice includes many of the same criteria as flow.

  • Clear goals and outcomes
  • Immediate feedback
  • Pushing your skills to their limit

Source: Jory MacKay of Zapier

Here is my take on the climbing rules that can be applied to writing software.

Learn to use the tools that you have well

This includes processes, any tools and structures that are there. The translation may be a bit off here, as the original read “Climb on the holds. Whether you like them or not.”; in (indoor) climbing you have a difference in holds for your feet and hands, and different shapes.

The tools that you use every day for writing software should hold no secrets anymore for you. Learn keyboard shortcuts in order to minimize mouse movement to get things done, or know how to debug your code using the built-in tools within the IDE. Know the language you are writing in and understand what the logic does instead of simply cut-and-paste from Stackoverflow. Tools such as code completion in your IDE can help, and debugging is an art that requires practice.

Try various techniques to accomplish the same result.

There are always other ways to accomplish a certain result, some might be better suited, either based on your personal style or preference, or for the project that you’re working on.

David Heinemeier Hansson, creator of Ruby on Rails, mentioned in a RubyConf keynote that writing software is like writing prose. A writer creates a draft for a piece of text, and tries various techniques in order to convey the opinion/information in a clear way (increase clarity).

When you practice software writing, you can try out various techniques in order to get the same result (similar to writing drafts and rewriting). One of the techniques might then pop-up as being the most clear and understandable, conveying the logic in a readable and unambiguous way.

Pick an impossible project. Now pretend it is possible

For any climbing route there is a grade of difficulty, to provide you with a guidance that a route might be climbable for you or not. A few years ago when I regularly climbed indoors, my partner and I would occasionally find a route that was way above our level, and try it out anyway, sometimes only doing short sections. Climbing above your level does help you overall, and the same goes with programming.

How often have you found yourself stuck in a piece of code that isn’t comprehensible or so complex that you can’t make heads nor tails out of it? Or something that you haven’t dared to modify in a long while because you don’t know how it works?

Now pretend that is possible to rewrite that, and that you know what it does. Take it in step by step, cut it up in pieces, after a while you can figure it out, and make it more clear.

Take something away

Practice with a handicap, taking something away that you take for granted in your everyday work. Will Anglin speaks about climbing without your thumbs in order to improve your technique, as an example.

For programming you can think about not applying your default frameworks and helper classes, and use the built-in functions and structures of the language you’re writing in. Or if you want to go hardcore, take away the help of code completion in your IDE.

Stop complaining

It is energy spent to complain about problems that you face. Deal with them, and figure it out, or leave it be. It is fine to call it quits on a project for now, and leave it be if you’ve concluded that it is for now beyond your reach. Don’t complain about it then, that effort should have been put in figuring it out.


Deliberate practice is a skill that you can learn, and provides you with a challenge that should help you improve. I find that mastering your craft feels a lot better then empty success.

The following two books/videos also touch upon the topic of deliberate practice and flow from an outdoor adventure sports perspective. Both have helped me to put the concepts into perspective.

Steven Kotler, “Rise of superman” - Steven Kotler - Talks at Google

Tommy Caldwell, “The push” - Tommy Caldwell - Talks at Google

P.S. If you’ve enjoyed this article or found it helpful, please share it, or check out my other articles. I’m on Instagram and Twitter too if you’d like to follow along on my adventures and other writings, or comment on the article.