Lifting weights in the gym has taught me valuable lessons that helped me improve as a software engineer
When building muscle, an athlete has to adhere to certain rules. The laws of physics, first and foremost, but studies also show that some training methods are superior to others. Most of these methods seem obvious but if you are lazy like me you have caught yourself going to the gym doing the same exercises with the same weights time and time again.
It took me longer than I would like to admit to understand that simply showing up to the gym is not enough to make progress. By the same token, if you never challenge yourself at work, your skills as a software engineer will not improve as fast as they could.
In this article, I introduce four weightlifting concepts that can be translated into software engineering.
The first concept I want to introduce is progressive overload. It has been around since the 1940s and belongs to the Exercise Science canon today. Progressive overload—according to Wikipedia—“advocates for the gradual increase of the stress placed upon the musculoskeletal and nervous system.”
The increase can be achieved in different ways. An athlete can do more sets and reps in a session, go to the gym more often, or simply put more weight on the bar. When it comes to your programming job, I do not want you to do fewer coffee breaks or work long hours.
It is possible to be great at what you do for a living while still leaving time for other interests. In fact, my interest in weightlifting helped me progress as a software engineer which is the entire point of the article.
To achieve progressive overload at your job, you have to lift heavy. Pick tasks that make you uncomfortable. You cannot improve as a software engineer if you are sticking to problems you can solve by only reading the headline of a Jira ticket.
I do not recommend trying and deadlifting 500 pounds if you have just learned the movement but you have to gradually increase the weight. You have to lift heavier than yesterday.
Muscle confusion is highly controversial in the fitness industry. There isn’t a lot of scientific evidence to back it up yet some gym-goers believe that they will get better results when they switch up their routine every now and then.
Even if science declared muscle confusion as a hoax, there is a problem with the existing research: it assumes well-balanced training plans that are executed with professional supervision. It does not account for awful exercise selection or bad form. If you are not making any progress, it might be time to look for another routine.
Unlike muscle groups, programming languages, frameworks, and paradigms are infinite. You cannot excel in all of them. A well-balanced tech stack that covers all relevant technologies can therefore not exist. There may be multiple stacks that are ideal for your project but to make the assessment you need to know what’s out there. How do you know the best tool for a job if you just know one tool? When all you have is a hammer, everything looks like a nail.
I learned the most when I changed teams. Especially the architectural and organizational changes turned out to be the most valuable. It doesn’t matter whether your team uses Angular or React but it makes a huge difference whether you are working on a monolith or a microservices architecture. If there is nothing left to learn, it is time to move on.
The order of exercises plays an important role when creating a workout routine (called programming, ironically). As muscles fatigue in a somewhat linear fashion, determining the order is rather straightforward: do the most important exercises first. Move from large muscle groups to smaller ones. In an office setting, there are different peaks and droughts that vary from person to person.
Prisoners are more likely to be granted parole early in the day or after lunch, according to a 2011 study. If you are like the average Israeli judge, your concentration peaks in the morning and after a break. Not everyone is an early bird, though. I consider myself more of a night owl and at the time of writing the clock is slowly creeping toward midnight.
It is always good to know when you are at your best. Try to figure out the circumstances under which you produce your best work. Solve the most difficult problems at that time.
If your employer allows for flexible working hours, make use of it. Some of my peers like to come in early, others take long breaks to pursue their hobbies (have you tried weightlifting?). Working off-peak hours gives you the ability to get stuff done without being interrupted.
A good workout is not a list of exercises that you want to check off as fast as possible. Instead of worrying about all the work that is left, you should concentrate on exercise execution. Maintaining proper form helps you avoid injury. Form beats volume and speed.
Similarly, you can rush from one developer task to another but the quality of your work may suffer. Implementing a feature quick and dirty without thinking about the overall design will leave you with technical debt. Your manager will praise you for moving fast but there will be a point when you have to explain to them that you cannot build anything new before all debt is eliminated. Don’t let it get that far.
Try to do everything to your best ability—even if it takes longer.
- Lift heavy: Work on problems that make you slightly uncomfortable.
- Switch it up: Look for another project if you are not learning anything new.
- Order: Find out when you are at your best and tackle the most difficult problems at that time.
- Form beats volume: Try to do everything to your best ability—even if it takes longer. Do not accumulate too much technical debt.
This is not a guide to weightlifting. Please take all sports analogies with a grain of salt—their purpose is to deliver advice to software engineers. If my story sparked interest in resistance training, however, I recommend you check out the resources below. Either way: Thank you for taking the time to read my story.