Monday, March 13, 2017


First, my apologies for the late blog post.  Had a busy weekend, but it actually works in your favor, as this idea struck me during my morning workout today.

The phrase “it’s not a bug; it’s a feature” is a common punchline in the tech world.  It’s about using marketing to solve technological problems; reshifting the perspective of the buyer rather than “fixing” the problem.  Basically, you’re telling the consumer that they don’t know what they really want, and those things that they perceive to be malfunctions are actually the product performing exactly as designed.  Though this is usually a hail Mary from a tech company to keep their customers happy, this mentality is pretty crucial for training, because many people need to shift their perspectives to understand that those things they believe to be “bugs” about training truly are the features.  This is what you WANTED; didn’t you know?

 Image result for giant nacho platter
Ok, THIS is probably what you really wanted

We witness trainees’ first encounter with “bugs” all the time when it comes to training, and many times, they are trying to “fix” them.  “I really want to do more conditioning, but whenever I try it, I feel like I’m going to throw up.”  Yup.  Congrats.  That means it’s WORKING.  “The last time I tried lifting, I was sore for DAYS.”  Yup.  That’s how lifting works.  “I tried working out in the morning, but I was tired.”  Yup.  That’s how being a human works.  “I did squats, but now my legs are big.”  Jesus Christ, are you serious?  That’s not a bug; it’s a feature!  Your training is working!  The process is occurring!  This is the avenue of change.

Most regrettably, we have been conditioned to believe that discomfort is a sign that something is wrong, and it requires immediate addressing in order to “fix” this.  This was once a helpful instinct to teach us not to touch fire and not eat a pineapple whole, but has become somewhat less helpful in a society where discomfort is no longer the norm.  Our forefathers and ancestors existed in miserable conditions as a matter of habit, and grew to understand this as the norm, such that they could tolerate it, grow stronger from it, get better and move on.  For them, this was not a bug, but a feature of life.  But for us now?  If discomfort CAN be avoided, surely it should be, no?

Image result for hedonism bot 
I mean, it worked for this guy

It’s amazing how eye opening this paradigm shift can be for the uninitiated.  I had a friend approach me on the topic of weight loss, as they’re starting their journey on that.  They’ve had success so far with counting calories and losing weight, but he asked me “What is it that you eat that keeps you from feeling hungry all the time?”  I looked blankly at him for a moment before I conveyed that I am ALWAYS hungry.  Being hungry is a state of being for me.  It’s how I know I’m still alive.  This blew his mind, because he was under the impression he must have been doing something wrong if he felt hungry while losing weight.  The idea that being hungry was part of the weight loss process was a new idea, and upon sharing it, it made his process so much easier.  Weeks later, and pounds lighter, he thanked me for essentially giving him permission to feel hungry while losing weight.

We have people trying to sell us the opposite!  Every weight loss product is about “effortless, painless weight loss”.  “Eat whatever you want and STILL lose the weight.”  Why is that such an effective marketing technique?  Because it goes against reality!  In reality, weight loss requires suffering, it requires effort, it requires turmoil, it requires NOT being stuffed 100% of the time and actually feeling the slightest twinges of hunger.  It’s not a bug; it’s a feature of weight loss.  It’s imperative for these companies to convince you otherwise so that they can sell you a “fix” for the bug they created.  It’s akin to those late night infomercials selling you a product that will speed up your computer by installing MORE malware when all you really needed to do in the first place was stop going to those websites that are full of malware.

 Image result for squatting on a bosu ball
I won't judge you for your fetish

And this perspective shift isn’t just limited to understanding reality for what it is; it can also help you cope with injury.  Injuries are notorious for being classified as “bugs” by the general populace, and surely something to avoid.  But what if it was a feature?  When I ruptured my ACL, it wasn’t a bug; it was a feature that allowed me to focus on my pressing, grip and neck work.  It was a feature that forced me to re-evaluate my approach to training and come up with a better way forward.  It was a feature that gave me an opportunity to overcome and get stronger in many ways.  I re-marketed my bug to myself as a feature, and came out better on the other side.

Don’t assume that simply because you meet some form of resistance or misery that you have encountered a bug in your training and programming.  Consult your inner marketing team and see if this may in fact be a feature.  Figure out how to spin it and sell it, and come out better on the other side compared to those people who just sit and patiently wait for the next software update that will SURELY get rid of all those pesky bugs.     


  1. Thanks for this. I turned calisthenics into a conditioning exercise and almost puked my third go around. Asked around, and some were all "that's normal", some thought i would hurt myself, some thought that i shouldn't be doing this until i have won medals.

    Glad to know its not only ok, but working.

  2. I know this is old but I don't think thats what premature optimisation is in CS. Premature optimisation is when you basically try to optimise the runtime of an algorithm before you even test what the actual runtime is.

    1. Essentially, yeah. Also, trying to optimize an algorithm when the compiler may be doing it for you, or optimization where it isn't actually needed because that function isn't used often compared to other functions.

      When I was taking CS classes, the big thing at the time was readability, and function sizes of 5 lines or less. It wasn't uncommon for

      void foo {

      void bar {

      and so on until maybe the actual logic was several function calls deep. Because computers are super quick with good memory so it is ok to nest a function call deep onto the stack if it means readable code. Been years since I touched a line and I don't know where the current theory is nowadays though.