Elijah Verdoorn

Programmer, Designer, Musician

5 Lessons from the Weightroom


Finding connections is fundamental to the learning process - the synapses in your brain are literally establishing new connections as you acquire new skills and knowledge. The more I’m able to draw parallels between the threads of my life, the more I’m able to multiply my growth and development. I’ve recently put some time in the weight room having fun training my body to do new things; some of the principles that I’ve learned about lifting have clear parallels to my familiar world of engineering.

  1. Put in the reps. Like programming, getting stronger takes time. You can do all the reading, all the research, all the preparation but at the end of the day there is no substitute for doing the work and gaining the experience.

  2. It’s not supposed to tickle. To get better at something, you have to get a little uncomfortable. It has been said “no pain, no gain”; I don’t subscribe to that phrase when it comes to exercise since pain can be indicative of an actual injury, but you should expect a little bit of discomfort as a part of the process of improving. When you’re lifting heavy weights you are destroying parts of yourself in order that they eventually grow back stronger; sometimes you have to do the same in your career. We have to make ourselves a little uncomfortable and take on progressively larger loads in order to become more effective and impactful, to do things that you’ve never done in order to learn.

  3. More is not always better. I am of the ilk that loves to push myself, challenge my boundaries, and find how far I can go. I’ve found that in the gym I have a tendency to always want to do more - add an additional exercise, do more sets, try out something new that I saw online. I’ve learned that I have to suppress that voice and stick to the plan otherwise I’ll run the risk of stretching myself too thin and being inadequately prepared for the next session. In the same manner when programming we need to be sure that we avoid taking on too much - we need to understand how much we’re capable of and not promise to do more than that lest we be unable to deliver. I’ve felt the same instinct that I have in the gym can arise in standup meetings and scoping - I’ll put more on my plate than I’m effectively able to accomplish. Holding myself down and making sure that I’m able to have the right-sized workload at any given time ensures that my job remains sustainable.

  4. Superset! For efficiency I often will pair exercises, working one muscle while resting another. A classic example that I’ve done is doing push ups in between sets of squats; as your legs rest you can get some chest work done. Similarly when we work on programming projects we can find ourselves with some downtime; this doesn’t have to be idle time. If we are solely focused on one domain we can always read, complete code review, or tackle administrative tasks. This isn’t really a surprising idea, but I’ve recently taken it one step further and will often work on one project while waiting on another - I’ll write back end code while my Android Studio compiles front end work, or clean up our Android code base while back end Docker containers spin up and tests run. I’m able to have a greater impact on my team and provide a larger overall contribution to my projects thanks to minimizing downtime.

  5. Get a spotter. In the gym there is no shame in asking someone to look out for you while you’re doing something dangerous; it’s important to have someone nearby to make sure you don’t crush yourself under a barbell! In the same way as engineers we should strive to normalize letting your team know when you are doing something new, telling them that you’d appreciate having eyes on your work to make sure that you don’t do any lasting damage. A good engineering spotter, like one in the gym, will let you struggle and strain a little but once they see you really faltering under the weight they’ll step in and take a load off so that you can live to fight another day.