What I learned about software architecture from running a marathon
Good code comes from motivation and fresh minds.
Delfo Cabrera Gómez, winner of the marathon race at the 1948 Summer Olympics in one of the most dramatic finishes in athletics history. (source: Wikimedia Commons)
So, if you know me, you would know I love to play video games, write code, and eat. Well, in my mid 20’s I realized that this combination can lead to a lot of unwanted pounds. So, somewhere along the way, I started running. Now at first, I considered it a successful workout if I could finish a block without running out of breath, then with time, research, and some bull-headedness, I was finishing marathons one after the next.
I’ve grown to love running for a number of reasons. One of those reasons is that it allowed me to do more of the things I loved to do, and do those things better. For example, If I ran more I could eat more, and I love to eat. In addition I found that running also made me better at playing video games and writing code. I’ll save the video game lessons for another time, but what I would like to share in this post are four things I learned from running and marathoning that have made me a better software architect and a better coder.
Learn faster. Dig deeper. See farther.
Preparation, or lack thereof
If you have ever run or watched a marathon, you will see at least a handful of people with two bloody stains on their shirts. Make no mistake: this is really painful, both because your nipples are bleeding and also because the whole world is seeing your nipples bleed.
So why does this happen? It comes down to preparation—or lack thereof—and it doesn’t just apply to nipples; it can apply to blisters, chaffing, dehydration, bowel movements, running low on food, and much more. These are all cases of understanding the difficulty of the road ahead and picking and applying the right solutions ahead of time.
In running, this means knowing and trusting your equipment and your training—for example, making sure your shoes are the right size for your feet after mile 10, or making sure you apply anti-chafing glide on the right body parts.
How does this apply to software?
In software, this concept of preparation is about understanding your tools, approaches, patterns, and designs. A good architect does everything purposeful, with research and discipline, not because of hype or hearsay about the next new tools or approach. As in running, a software architect knows that the cost of bloody nipples is too high not to have taken the time to truly know the strengths and weakness of every tool/approach that they bring on the long journey to building a solution.
Being always vigilant
The next big lesson I learned from running is not to be over confident, and always be vigilant. I can’t count the number of times I have seen strong runners do everything right in terms of preparation, and then hit a pothole or speed bump and BOOM! All of that training, all that prep was for nothing, and now they have a leg sprain and 21 miles in front of them, or the “meat wagon” (a big bus that picks up the slow and injured) behind them.
In software, we can take this lesson and apply it toward identifying risks, and always being vigilant in looking for weaknesses in your approach or tools. One misstep in software could cost your project weeks in development at best—or at worst, additional oversight and the possibility of disbanding your team. Just as in running, overconfidence is your enemy. Continue to look for weaknesses in areas such as throughput, multi-tenancy, security, and more.
Walk breaks
A common misconception about running long races is that you should run the whole way. I learned to run from following Jeff Galloway’s run/walk strategy. The idea is you will finish a marathon much faster and with fewer injuries if you take walk breaks, or if you are an elite runner, you at least take moments to enjoy a slower pace.
The idea is simple: the body needs time to recharge and rebalance. A marathon is a long race that, at best, can be finished in a little over two hours, but if you are like me, four to five hours is more your timeframe. The goal of the run and walk strategy is you have more energy and are less prone to injuries toward the backend of the race—and the backend of the race is more critical to your success than the start of the race.
Taking walk breaks in software
This idea of walk breaks is also extremely important in software. In my time at Cloudera, I have worked with more than 100 different software companies, and I have learned that good code doesn’t come from an army of tired people doing 60-80 hours of pounding on the keyboard. Good code comes from a few good people with motivation and fresh minds.
In software, a walk break is as simple as a weekend of no work—or better yet, allowing for one day a week to work on a different project to inspire ideas and change up your thought patterns. Not only will this make good developers better at their jobs, this will make you stay with your company longer. Almost all of my good ideas for code were not thought of in front of a computer, but on a walk, a run, a moment taken in meditation, or over a beer with friends. When the mind has a chance to recharge and rebalance, it tends to work on the problems of the day in the background, and the result is usually a great idea that can become a game changer.
Rollercoaster of emotions
The final lesson from running a big race is about emotions. Every time I’ve run a marathon, I was full of energy and the excitement that comes in the beginning of the race. In a marathon like the Marine Corps marathon or Disney’s Goofy’s Race, it feels like being in a moving stadium of tens of thousands of excited fans. But as the race goes on, different emotions happen almost like clockwork.
- Miles 1-3: excitement
- Miles 3-13: strong and chugging away at the mile
- Miles 13: small bit of relief knowing you’re halfway done
- Miles 13-16: a lot more quiet
- Miles 16-23: people starting hitting the wall and things get tough
- Miles 23-25: a lot of mixed feelings: exhaustion, pain, gritting of teeth, noticing the mile marker seems farther and farther away
- Miles 25-26.2: BOOM—the end is in sight! The pain is still there, but you can see through it. Your pace increases and you are overwhelmed with joy and excitement.
Running the lifespan of your project
In software, we can experience all of the same emotions over the lifespan of a project. Most of us have experienced the joy of starting a brand new project, excitement about what future technology we’re going to be able to use, and the joy of thinking about the problems we’re going to solve. Similarly, we also know what it means to hit a wall. In running, it is this overwhelming feeling of exhaustion and wanting to give up; in software it is that moment you just want to bang your head on the desk because there seems to be no solution, and the problem is unsolvable.
The thing that running a marathon gives you is a deep physical and mental journey into this emotional spectrum, over a short timeframe. This can actually help you develop the mental fortitude to keep a steady head through all stages of the software development process. In the end, this mental fortitude can result in a more disciplined, thoughtful, and goal-focused development, with less hype.
Crossing the finish line
In closing, try it. You don’t have to run a marathon—it can be a 5K. You don’t have to be fast—heck, my last marathon took more than five hours; but if you do try a race and go through the process of training, when you cross that finish line, you will see what I’m talking about. There is something very primal and very human that you experience when you finish a race, and that same experience applies very much to development—the art of building solutions that change the world, with the power of our minds and imagination.