5 Ways Being a Fitness Instructor has Helped Me as a Software Developer
My career is split in two: fitness and software. When I’m not training clients at a health club I’m developing applications for a firm in San Francisco. Having such a drastic balance allows me not only to keep a mental sanity by not sitting too long at the computer but also to share and apply concepts across each realm. Here are five focus items in fitness that I apply regularly in the code.
Underlying Motivation
Always question the reason why a feature is requested. So often a client will ask for a feature that doesn’t jive with the flow of the other moving parts in the system. Blindly implementing a feature can potentially waste time and cause frustration — not only from the customer potentially not getting the result he/she was hoping for, but also from the dev going against a gut feeling and years of experience that pulls the other direction.
In fitness, this is typically presented as “I want to work on my mid section” or “I want to lose ten pounds.” Okay, why? Knowing that spot-reduction is a myth and you can’t burn fat in one part of the body simply by contracting nearby muscles, “working the mid section” doesn’t really make sense to achieve any sensible goal when accompanied with weight loss as an objective. Are we talking about alleviating back pain or trying to correct hip posture? Great. Toning the tummy? Nope. As a trainer I could have you doing ab work for 2 hours and you won’t tone your tummy. You’ll just get sore and frustrated.
Why ten pounds? What happens at ten pounds? Does the ten pounds have to be fat? Because I can put you in the sauna and you can lose a lot of water weight. But that makes no sense and is dangerous. Muscle is denser than fat so it weighs more by volume. Should we catabolize muscle for a quick ten pound muscle loss? Of course neither of those suggestions are what the client really wants. Typically, ten pounds means “I want to lose enough weight to notice and so my peers notice”, and ten pounds is the magic number that appears on so many magazines near the check-out counter.
Okay what will happen when your peers notice you’ve lost some weight? You’ll maybe get some compliments and feel good. Now we’re getting somewhere. Getting a haircut or new shoes often yields similar results. Why 5 weeks with a trainer at $100/hour instead of a $100 haircut that would offer instant gratification? Ultimately, clients want to be happy. They see fit people around them and want to be like them because they think it will bring happiness. This is an intrinsic need vs a confused and misled extrinsic want. Knowing that happiness is all the client wants, I can prescribe an extremely enjoyable fitness session that he/she will want to continue indefinitely and will likely no longer care about the ten pounds and toned tummy. Those things will happen as a side effect and since they're not the main focus, both the trainer and the client satisfaction will greatly improve.
Applying this to a software application, clients often ask for minute and unwarranted visual changes. “Darken the purple on this button”, for example. Why? Was there an A-B test I didn’t know about where a darker purple button yielded a higher click-through? Or does the client just like dark purple? At the end of the day we do what the clients ask of us, but we can’t forget that usually what they want is a profitable product and a justifiable ROI on development services. If the client wants a higher click through, lets A-B test some things: color, placement, and call-to-action text perhaps. It’s no longer about purple, then, but rather about monetization strategy. If the client just really likes purple, he/she then probably just wants the app to reflect his/her personality more. The app can then be shown to peers and customers with more of a “this represents me” dialog. If that is the case, it really helps to bring up a branding strategy with the client to eliminate one-off color changes that seemingly waste a dev’s time. The client will be happier that we deeply understand the underlying motivation and the deliverable will be exactly what the client wants.
Core
Most people confuse abs with core. This is because cheap fitness equipment informercials falsely market on the word to make more money. It’s a buzz word.
Your superficial abs that you see in the mirror (or will soon!) are not your core. Your core are your deep tissue spinal stabilizer complex. They work to keep your spine in alignment when resistance and support stray from the mid section. Think of holding a weight at shoulder height with your arm straight. In front of you or out to the side, your core works to keep you from falling over. In a push up, your core helps keep your hips from sagging and actually plays a much larger role than your chest and triceps.
When your core is weak, all exercises suffer. Push ups are hard, squats are hard, and any overhead press is hard and also dangerous. Focusing on auxiliary muscle groups while neglecting your core is how people get injured: it develops a false sense of confidence and people think they are ready for advanced exercise programs. Then they slip a disc in their back and are out for 6 months or more. This typically occurs from training exclusively on selectorized machines, which support your weight and isolate auxiliary muscles so your core doesn’t have to work at all during the exercise.
In software, I never forget the importance of the concept of a core. Foundational code and design patterns that can’t and won’t break, and allow us to grow the application outwards, are critical to have in place before focusing on auxiliary application logic. For example, in NodeJS I have my core patterns for authentication, permissions handling, cache, service layers, and utilities. My application logic then is simply compositions of those core modules. This often clashes with agile and iterative development projects where “quick prototyping” has to be done to show investors demos of “working concepts.” Sure, fine. But the moment we pretend that demo code is permanent and will live inside the application is the moment upon which we can all look back after the app fails and say “that’s where things started to go wrong.”
Misdirection
The human body can fool the brain. Often times a signal will be fired along a neurological pathway and the brain will interpret the signal incorrectly. This happens all the time and with a wide range of scenarios. For example, when we feel hungry, we’re often thirsty. When we feel mildly thirsty, we’re often already dehydrated. Drinking a glass of water and waiting 5 minutes can often make hunger go away. I live by this, and so should you! Staying hydrated while controlling calorie consumption is 90% of “how to get a 6-pack”. Another common scenario is sciatica. The sciatic nerve runs all the way down the leg and up behind your piriformis, near your sacrum. Often times sitting too much will cause the piriformis to inflame from the sacrum pressure, and will transition that pressure to the sciatic nerve. Often times, the pain is felt locally (in the glute region), but equally as often, the pain is felt remotely near the knee. Clients will complain about knee pain and don’t realize it’s being generated nowhere near the knee. Foam rolling and stretching out the glutes and piriformis alleviates their “knee pain” and what appears to be a miracle is basic physiology.
In software, this is extremely common. A dev will hit a bug and get tunnel vision trying to fix it, not realizing the cause of the bug is in another function or another file. This often happens in mutable state applications where function A accepts a reference to an object and mutates it. Then function B uses an externally scoped reference to that object and expects it to have been affected by function A. Using pure functions who’s output are defined by their input and have no side effects can greatly reduce occurrences of this headache. Function A receives an object and returns an altered copy. Function B should accept that copy and not know anything about function A. This style of programming can save hours and days of debugging time which can add up to several thousand dollars.
Having said that, legacy and monolithic code bases exist and mutation is real. Taking the sciatic nerve example, I always propagate up the reference tree to reserve blame and let the code prove itself. Just because you see an error on line 150 doesn’t mean it was thrown on 149, and knowing this sooner than later is crucial to maintaining a high development velocity.
Kinetic Chain
The kinetic chain in the human body is simply the idea that movement in a joint can affect movement in another joint. This is caused by muscle origin and insertion points and how flexion and extension of a joint will change the point of tension. For example, one of the most important form corrections I give as a trainer is keeping the knees back behind the toes while doing a squat or a lunge. If the knees travel forward past the toes it typically creates an acute knee flexion angle which requires the quads to do all the work to re-extend the knee so you can stand up again. All that force has to go somewhere and it typically gets passed down to the anterior cruciate ligament (ACL), which is arguably the most commonly injured connective tissue in the body. What we want is for the hamstrings and glutes to do most of the work, so the force remains in the muscles and in strong joint positions. How we do that is by keeping the knees back and pushing off the heel instead of the toe. How we do that is by forcing an anterior pelvic tilt, and how we do that is by sticking our butts out and forcing a lower back curvature.
Just as it’s not intuitive for most people to think “I should focus on my glutes and back position to avoid a knee injury” while doing a squat, it’s arguably just as unintuitive for most developers to think “I should write a strategy for this remote service so that I won’t have to change the expected payload on the client if/when we change service vendors.”
When writing modules, I always consider that other parts of the application will depend on this module behaving a certain way, and so if the module ever changes, how can I minimize that ripple effect?
Measurable Goals
Just as I mentioned earlier, clients often want to lose ten pounds. And yes, we can measure that with a scale, and yes, the scale has no idea what accounted for the ten pounds: fat, muscle, hair, clothes, pee, poo, etc. For this scenario I always measure and compare body fat percentage. Most clients aren’t even close to that level of goal setting, and request “I want a bikini body” or “I want my high school body back.” Not all are that superficial, and say things like “I just want to be healthy.”
How do I as a trainer know if I’ve succeeded for any of those subjective requests? What I think is a bikini body might be nothing like what the client expects. Setting realistic, measurable goals that are checked and prioritized regularly keeps everybody on a clear path to success. “I want to run a marathon in under four hours” : yes, let’s start training. I can plan an exercise prescription for that, and we’ll both know when the goal has been reached!
In development, it’s absolutely critical to set measurable goals, or as I typically refer to them: acceptance criteria. When a user story is created in Jira or Pivotal, it’s fine to be vague in the title to spawn some dialog among the team. “As a user, I can find products I like.” Great, now what the hell does that mean? Some people search, some browse the catalog, some expect a “recommended for you” list on their landing page. That story is useless without one or several end-to-end UX definition(s), each accompanied by itemized steps of confirmed success. Providing that not only keeps the dev focused and on a fast pace, but also removes debate from the client or PM when ticket is resolved because the tasks are objective instead of subjective.
Finding commonality across various industries I think can really solidify best practices all around. As we learn, let’s share the knowledge and experience gained with our peers and move forward to be the best we can be.
