Category Archives: Parkour

Parkour and Programming

In my free time, I sometimes practice something called Parkour. In fact, my username (MarkTraceur) comes from that art, because “traceur” is a term for a person who practices Parkour. This art is a very intense physical discipline, combining simple, natural movements with martial arts techniques to form a set of “best practices” when it comes to moving through obstacles. In reality, it’s just a set of tools that help you evaluate problems of efficient movement.

Well, since the rest of my life is dominated by software, the natural thing to do is to compare Parkour to programming, and see if I can’t learn, and teach, something interesting. First, I should probably explain how I see Parkour.


Parkour, as explained above, is an art of movement. It helps you train a set of movements to the point where you’re very comfortable with all of them, and can easily reach for and execute the best movements for any particular situation. These movements include such things as vaults (for getting over things), wall-climbing techniques (for getting up things), underbar techniques (for getting through things), jumping and landing techniques (for getting off of things), and other more general movements.

Parkour isn’t just about exercise and practice, though. The community and organized practice of it was mostly started with the mantra “be useful”, and there is a lot of philosophy that goes with it. There’s also a huge slew of mental preparation a person needs to do in order to do some of the movements, and even judging the best movements for a situation takes a lot of thinking.

The really interesting thing about Parkour, to me, is that there never seems to be a single “best” way to do things. While most people would look at a situation and agree that one movement or another seems good, another person might come in and have a different idea that works better for them. For example, while going over a rail with a speed vault might be good for me, a shorter traceur might be better served by going under it with an underbar. Many of these questions share a similar non-deterministic quality that really appeals to me.


While my blog is mostly frequented by technical people, I expect this article in particular might draw some traceurs who don’t fully understand programming! So, I’ll try to explain what’s necessary for this article.

Programming is the act of telling a computer, through a list of commands, how to behave and what to do. For example, as you’re reading this on your web browser, your computer is likely listening on a network interface (wifi, 3G, 4G, or ethernet) for connections. It doesn’t do that because it innately understands, but because a programmer somewhere wrote the necessary words that told the computer “wait here, and listen for this data, then perform this action”.


The really cool parts about programming and the really cool parts about Parkour, I think, seem to cross pretty regularly. In programming, I often come across a situation where the solution I create might not be the one someone else would use. Most of the time, these solutions differ in their speed, or in the amount of memory they use, but depending on what you’re trying to accomplish, either one might be “best”. Admittedly, there are certain things (like “crash the computer, delete all the files”) that would almost always be excluded from being the “best”, but there are so many different qualities of each solution that most of them will be good in one way or another.

But the fun doesn’t stop there! Most traceurs will continually train their skills over and over again. Well, programmers do that, too: The more we write in any language, the more fluent we get with it. The first time you use a language, you jump straight into it and try really hard to use it anywhere you can. Once you learn the language well, you keep building on that knowledge with additional libraries, additional and more difficult file structures, and so on. Traceurs will be familiar with this concept, called “progression”.

Even some of the simple philosophical ideas bridge the gap. Where traceurs say to “be useful”, most programmers will also recognize a similar concept. Where software is free, it’s common courtesy (or sometimes legal obligation) to release derivative works as free. Where you download a file, it’s common courtesy to mirror it if you can. Where you fix a bug in a free library, it’s best to contribute that fix back to the original author. This is also similar to the general traceur practice of leaving a training spot better than how you found it.


The biggest difference between these two art forms is the physical involvement inherent in Parkour. This makes it an extremely difficult thing for a beginner to do with any sustained effort–the physical demands of hauling oneself up and over walls repeatedly is not to be taken lightly! For those of us who love sitting in front of flashing pixels for hours (or days) at a time, it’s very difficult to start.

Another huge difference is that, in software, there are a lot more concrete solutions for specific situations. In some places, there are well-known mathematical proofs that show the superiority of one solution or another. This is a result of two other differences: One, programming has been around, and popular, for a lot longer than Parkour. Two, programming is much more concretely defined, due to its mostly-deterministic nature. Above, I described the non-determinism as being a similarity, but programming was a lot closer to being deterministic than Parkour.


For programmers

  • Parkour is fun! If you haven’t tried it, and you’re in the Bay Area, feel free to contact me and drag me out on a run.
  • Being useful, and generally being helpful to your community, is a great philosophy to have. It makes for a really cool community, and it makes you feel good!
  • Thinking about a problem as having more than one “good” solution is more productive than thinking about it as having only one “best” solution. Maybe you’ll eventually decide that, in this situation, there is a best solution, but not necessarily acknowledging it will help you to generalize the other solutions for the next time!

For traceurs

  • Programming is fun! Maybe it doesn’t seem like it, but there are a lot of similarities between these two disciplines. If you love the mental high you get from computing paths through a course, you’d also love the mental gymnastics involved in getting a computer to do what you want!
  • Other communities have similar philiosophies to “be useful” and “leave the spot better than how you found it”, so keep doing those things! In particular, contributing to the community is a really great thing to do, and traceurs (and groups of traceurs) should make that effort a priority. Even just welcoming the community into your training sessions is a great benefit.
  • If you don’t already consciously consider that multiple solutions might be desirable in a particular situation, try! Next time you go out, do your normal training exercises, but then turn around and look at the obstacles a second time. Consider what you might do if you were shorter. How would you get through if you had a broken arm? What about if you couldn’t touch one of the obstacles for some reason?
  • Thanks, as always, for reading, and go freely!