what software engineering taught me about running

People who have known me (or followed me on Twitter) for long enough may have noticed that I like to make bad “jokes” that contain weird references to computer science or running — or, worse, both at once:

Also, my attempt to juxtapose “running Marathon” (the Mesos orchestrator) and “running a marathon” (the 26.2-mile foot race), which even I decided was too cringe-worthy to tweet.

Anyway, here are a few things that I’ve learned in ~3 years as a software engineer that, surprisingly, translated into useful lessons when I started running.

impostor syndrome

I think this is actually pretty self-explanatory, but I don’t want to downplay how long I struggled with it. It was many months before I finally felt comfortable calling myself a “runner” and not just saying “oh yeah, I run a few miles a couple of times a week.”

Impostor syndrome as a software engineer: everyone else seems to know so much more and ship faster, and OMG it’s taking me forever to find and fix this cryptic bug in this new JavaScript framework I just learned!

Impostor syndrome as a runner: everyone else runs faster, farther, or faster and farther, and OMG I can barely huff-and-puff my way through one 10-minute mile!

Overcoming impostor syndrome, for me, requires two things: 1) actively detecting when I’m hitting one of those mental slumps and reminding myself of my accomplishments and 2) giving it time — over time, you naturally progress as you work on bigger projects, learn new languages, go on longer runs…

building your mvp/foundation

You need to start with something that you can measure before you can make it better.

But to get that initial something, whether it’s your MVP web application or a first-time run of a certain distance, sometimes requires a “hack” or “shortcut” that goes against your better judgment. Maybe you hard-code your production database password into your source code, or maybe you do an intense interval workout while still recovering from a moderate injury.

You can push through like this for awhile, ignoring your brain’s warnings about adding yet another TODO: fix this hack someday! or the pain in your heel when your foot strikes the ground. You can grow accustomed to a codebase with “bandage fixes” for bugs or to an ankle that’s literally in bandages, but that’s not a healthy, sustainable way to live and grow. Eventually you need to refactor or rewrite, or to accept that the soreness is not “cumulative fatigue” but a real injury that necessitates proper treatment.

It’s easy to say that you should slow down and build it right, but when you’re literally racing against the clock, it’s much easier said than done. But be mindful of when the tech debt soars too high or when you’ve pushed yourself too hard, physically or mentally. If you have the willpower to build a new API in a short time or get through a hard training run, you have the willpower to tell yourself: I need to stop now and fix this / rest. In the long run, it is the only right choice.

quantity vs quality

Software engineers count lines of code (LOC). Runners count number of miles run in a week (mileage).

Obviously this does not mean that all software engineers care about LOC or that those who do only care about LOC, and ditto for runners/mileage.

That quantity and quality both matter seems so obvious that I don’t know how to explain it more. Quantity is a (relatively) easy-to-measure metric and (imperfect) proxy for experience: someone who has seen hundreds of thousands of lines of code has very likely been in the industry for many years, and someone who can regularly run 70 miles a week has very likely been running for years. It just takes time to gradually read and write more code and to build up your endurance or aerobic capacity.

But just reading/writing “bad” code or logging sluggish miles isn’t good enough. Quality matters because good craftsmanship is integral to software engineering, and it’s important to learn what styles and what design patterns work and what don’t and to apply those best practices in the code you write and review. Quality matters because you want to end a workout or run feeling good about yourself and perhaps meeting a more specific goal (like running at tempo pace for x miles).

having the right tools

You don’t need a ton of fancy tools to get the job done, but having some of the right tools will make it infinitely easier and more enjoyable.

In software engineering, tools might include your keyboard, monitor(s), dotfiles, editor, and various command-line tools or applications. In running, it might be your running shoes, clothes, GPS watch / activity tracker, or running band/belt.

Clearly, some of these tools are not cheap. There are some fundamentals, like a working computer or proper-fitting shoes, that are hard to go without. But the financial ability to experiment with some of the “extras” is a privilege, and personally, I deeply respect people who can do more with less.

Different people prefer or perform better with different tools. What works well for you may not work for somebody else. It’s useful to see what people around you, especially those whom you respect and who are very good at what they do, are using, but remember that YMMV (literally).

know how to recover

In software engineering, as in running, as in life in general, something inevitably goes wrong or not as planned. Knowing how to keep calm and effectively recover is essential — whether it’s a critical server crashing for unknown reasons or sustaining an injury right before a race.

At first, learning how to recover from many different scenarios sounds scary, but soon enough, you start to see common patterns.

In engineering, this might look something like: 1) confirm/reproduce the problem 2) mitigate or rollback 3) investigate and identify root cause 4) implement safeguards to prevent the same error from happening again and/or document how to quickly resolve it.

For many common, mild-moderate running injuries, start with RICE: 1) Rest 2) Ice 3) Compression 4) Elevation. If you have a more unusual injury, consider documenting it in case it flares up again (like a runbook, get it?).

Sometimes, things are more severe and you need to get help, whether it’s escalating to another engineer or consulting a medical professional. Over time and with experience, you’ll get better at diagnosing and treating small, common problems yourself and at knowing when to turn to someone else.


Popular food choice for programming/tech events (e.g., hackathons) and for carb-loading (e.g., dinner the night before a long race). Yum.