In August of this year, I competed in my first powerlifting competition. Having trained for three years total, and for eight months specifically for this competition, it was a big personal achievement. After the competition, when a bit of the training blues kick in and you’re a little unmotivated with no specific goal to work towards, I decided to reflect on the countless hours of training that went into the competition.

It occurred to me that not only had I gotten so much stronger, but I’d also gained some personal habits and traits that had benefited me outside the gym. When I first came up with the idea for this post, I initially dismissed it - I figured there wouldn’t be enough correlation between Powerlifting and Computer Programming to write an entire post on it. The more I thought about it, however, the more I realized they truly are quite similar disciplines.

Powerlifting is essentially Squatting, Bench Pressing, and Deadlifting the absolute most weight you possibly can. Believe it or not, there is math and science involved, and there’s a lot more to it than the stereotypical meathead who just goes to the gym and forces themselves to pick up the most weight they can, and I’ll get into that in a bit.

Programming boils down to solving problems using computers, by writing code to accomplish tasks. It’s not typically seen as the most physical activity, or anything related to a sport for that matter, so how can these two completely different acts have any correlation?

It turns out, they actually translate and even benefit each other much more than you probably think.

Progressive Overload

Progressive Overload is a weightlifting term, and it’s defined as the gradual increase of stress upon the body in order to stimulate growth - either in terms of muscle size, cardiovascular stamina, or muscle strength in the case of powerlifters. This could be increasing the number of repetitions (reps) you do, decreasing the rest time between sets, and/or increasing the amount of weight lifted, all over a period of time.

Deadlifting 447lbs.

The idea is that, like everything in life, you don’t grow by staying constant - you grow by forcing yourself to work harder and harder over time. This is pretty obvious in the context of powerlifting, because no rational person would expect to go to the gym and lift the same weight week in and week out, and become stronger. It just doesn’t work that way.

Growing as a software developer, like powerlifting, requires Progressive Overload . If you work on the same challenges, be it at work or during personal projects, you can’t expect to grow as a developer. If you aren’t encountering new challenges, how can you expect to hone your craft and becoming a better version of yourself? You can’t, and while we as developers never use the term “Progressive Overload”, it’s actually the exact thing we’re doing when we take on new challenges and push ourselves outside of our comfort zones.

Breaking Down Goals

Powerlifting, like software development, requires specific goals to be set from the beginning that you can work towards. If you sit down at a computer or stand in front of a squat rack without a goal in mind, what are you doing? You’re probably just going to end up messing around and getting nowhere in that session, because you don’t have something specific in mind that you want to achieve.

In software, we generally have a specific goal - build Product X. This could be a website, a script, an app, anything. We give ourselves a timeframe to complete the task, and from there we break the job down into smaller steps that we can use to track progress. Let’s say we want to release version 1.0 of a mobile application in six months time. We don’t just get to it and hope we hit that target - instead we break it down into smaller cycles, such as “sprints” in Agile development, and we allocate smaller goals to each sprint. These goals could be a particular feature, a part of the architecture, or anything really, so long as they can be reasonably accomplished within the current cycle or “Sprint”, and measured.

Similarly, in powerlifting, we set goals far in advance. Maybe you want to deadlift 500lbs in six months, or squat 400 in twelve. Whatever it is, you then break down your timeframe into smaller, measurable training cycles. These are generally, at least for me, about four weeks in length, and give you reasonable time to progress while still keeping the time frame short enough that if things aren’t working, you can adjust when you start the next cycle.

Sounds very similar to the concept of a “sprint”, doesn’t it? That’s because they both serve the same purpose, and are essentially the same thing. A small enough time frame to accomplish smaller goals, all while keeping the risk of lost progress minimal because the time frame is short enough that you still have time to adjust if things aren’t working or progression isn’t as quick as anticipated.

The Retrospective

At the end of a “sprint” or work cycle, in software development we typically perform a Retrospective. Essentially this is a review of the positives and negatives of the previous cycle (sprint), and determine what actions are needed going forward to ensure we stay on track, and continually improve upon the process.

This translates perfectly to powerlifting, and is one of the most beneficial aspects of software development that I’ve incorporated into my powerlifting training. At the end of each training cycle, I’ve found great benefit in sitting down and thinking about where I am and where I expected to be for each of the three main lifts. If progress is on track, generally there are only minor tweaks needed to keep progressing. However, when progress is not on track, you need to consider what actions you can take to get back to where you want to be.

Squatting 355 lbs.

For instance, if you find that you’re stalling on your deadlift progress, and you find that the toughest part is getting the bar up the first couple of inches, you may decide to take action and incorporate “deficit deadlifts” into your next training cycle, to specifically target that weakness. The following cycle, when doing your “retrospective”, you think back on what actions you previously took, and see if they’ve had any benefit. This continues, over and over after each cycle, ensuring that you’re giving yourself enough time to actually measure the results of your retrospectives, while still not wasting too much time if things don’t end up working.

Software development, just like powerlifting, is all about constant improvement, and the retrospective is a fantastic method of reviewing and enhancing improvement after each training cycle or software sprint.

The Folly of “Magic”

It’s easy to accomplish something and walk away without fully understanding why you accomplished it.

In software, this could be writing a complex piece of code, ensuring it works, but not knowing exactly what’s happening. In powerlifting, you’ll have days where you feel like you can lift way more than usual, or a new technique feels better than what you’re used to, but you don’t know the inner workings that make it so.

Both practices require a solid understanding of what’s going on under-the-hood in order to improve. Claiming it’s “magic” is a common outcome for junior developers and powerlifters alike, and learning the inner workings is something that comes with experience, but it’s important to understand the fundamentals sooner than later so you can use them to your advantage.

Knowing why a particular piece of code deadlocked or why a low-bar squat places less stress on the knees is easy to overlook for some, but the best programmers and powerlifters figure out exactly why something is the way it is, and use that understanding for future growth. Given the deadlock example, if you take the time to dig into the problem after solving it, and understand exactly what caused the issue, you’ll be much better suited next time to solve or prevent the issue from ever occurring. Similarly, the low-bar squatter will be better equipped to prevent knee pain if they understand the “why” than someone who simply accepts it at face value and walks away.

Knowing When to Grind it Out, and When to Step Back

For every powerlifter, and for every developer, there come times where you feel like you’re banging your head against a wall. Maybe it’s a new technology or a bench press record you just can’t seem to get through. You may know why you aren’t making progress, or you may not, but it’s important to know when to stick through it and keep pushing.

There’s no exact way to know when you need to grind it out and when you need to take a step back, it’s something that you need to answer for yourself. You can use previous experience to guide you, or the input of others, but ultimately it comes down to intuition. Are you making any progress, however small, towards breaking through the sticking point? If so, that’s probably a good indicator that you can keep pushing and break through the wall. Even if you aren’t making progress, it’s important to consider your position and determine if you can make it through.

Bench Pressing 237 lbs.

Additionally, it’s quite often appropriate to take a step back. This could be seeking assistance from colleagues, taking a “deload” week from training (significantly reducing the weight you train with for a week before continuing), or adjusting your technique.

In software development and in powerlifting, it’s crucial to know when to take which approach. Quitting too early gives you no chance to grow, and continuing in futile effort will leave you frustrated and unsuccessful. Both groups of people need to learn for themselves when they can push through and when they need to take a step back.

The Boring Stuff

Unit testing, foam rolling, code reviews and warm-up sets. None of these are (generally) what we’re passionate about, but powerlifting and programming alike have many mundane aspects to them that are required to grow and improve ourselves, and our crafts. In powerlifting, avoiding the mundane tasks generally leads to poor performance, and potentially injury. In software, ignoring these tasks can lead to poor performance as well, and potentially bugs.

With both practices, it’s extremely important to remember that the “boring stuff” is critical to staying on top of your game, and building these tasks into your daily ritual can go a long way in ensuring they get done. It may not be the most exciting work, but keeping in mind that it will benefit you greatly in the long run will (hopefully) help you push through, and get back to the fun stuff.

The Right Tools

Knowing the right tools for the job is crucial to powerlifters and developers alike. It may be which language or editor is right for the job, the frameworks available for the task at hand, or the supplementary exercises and equipment that are right for your lifts.

Testing, tweaking, and learning the tools you use is beneficial for both activities, and it goes back to The Folly of Magic where the lifter or developer who truly learns the inner workings of their tools and techniques is going to have the upper hand over the individuals who just accept them at face value.

First place in the 63kg weight class.

Why You Do It

It’s important to stay grounded and to remember why you do anything. For powerlifters, this could be knowing why you’re dedicating months and months of training for a competition, or why you’re spending so much time in the gym when you feel like you’ve plateaued.

Developers too must remember why they do what they do. Why do you put in the extra effort to keep your code clean and maintainable, when you know you could just bang it out in a few minutes and be done with it? Why spend the extra time testing trivial methods when surely the code is simple enough that it doesn’t warrant the extra effort?

Knowing why you do what you do helps you focus on what’s important, and push forward even when you’re lacking motivation or if you feel like you’re headed down the wrong path.

And Of Course, Caffeine

Energy drinks, pre-workout, coffee, tea - everyone has their source.