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?
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?
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.
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.
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.
ReplyDeleteGlad to know its not only ok, but working.
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.
ReplyDeleteEssentially, 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.
DeleteWhen 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 {
bar();
magic();
other_stuff():
}
void bar {
more_magic();
were_all_nerds();
}
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.