Distance Running and Software Engineering

Have you ever found something you enjoy so much that you just want to continue doing it for as long as possible? Is it coding? Is it building things? Well, for me it is.

What about other things that you enjoy? Are they similar or different to what you enjoy the most? Are they completely different? It's fine either way. But does one complement the other in a way you really never thought it would until you really got into it?

Distance

Distance running is that other thing for me. I did not get into running until more recently in my life, but it has been one of the things in my current life that has helped me be a better engineer.

"What?" Yes, something non-technical has helped me be a better engineer. "How so?", you may be asking; well, let's go through some of the things that are in common and have helped me. On your mark, {airhorn}. (I promise, I'll try and keep the racing references to a minimal.)

In the Zone

The one thing I enjoy about coding is getting into the zone. That state of being where you are so focused at getting something done and everything and everyone around you are out of mind. The joy of being in a rhythm and a constant cadence of feeling productive; always working towards a goal whether it be something small or something large (maybe both).

Now, what if I told you that I feel the same way when running? The feel of being in the zone; that meditative state, clearing your thoughts and constant cadence. For the non-runners out there I can probably get a sense of skepticism coming, but this feeling is felt by other runners. If you don't run, think about something else you may do that is calming for you. I've heard that knitting, baking, or gardening are also quite calming.

Finding that passion outside of work has been such a pleasant surprise. It's a wonderful day if I am able to get into the zone and clear my mind whether it be with running or programming or even both.

Team Work

As a software engineer, I have a team that comprises of other engineers, a tech lead, a product manager (PM), an engineering manager, a designer, and a Product Marketing Manager (PMM). What is my role within the team? If you said, "code", yes, you are absolutely correct. But that is only part of the answer, because afterall, software engineering is not all about code. (Something I had only come to embrace later in my career.)

Let's think back to running again. So as a person who likes to keep on track with goals, my natural progression in running drove me towards racing. Let's think about that word rigth there first, "racing". You typically think of racing as a competition where you would be running to get to the finish in the fastest time posssible. While this is mostly true, for most folks it's really just a competition with yourself; a competition to compete with your former self and get to that finish line faster than you had done before. You can think of the elite runners and of course they're competing to finish first. But for most of us, we're simply competing to get that personal best.

I've learned to think of pace as a team effort. When running with others, I'll sometimes make that concious decision to pace slower to pull other runners along with me and have us draft together; working together. But thinking this way has also been good for me as an engineer. While I may be a fast programmer (sometimes), if I am the only engineer that is fast does not necessarily mean the project I am working on will be finished earlier. What happens then, if as a team we work together, whether that means me taking some time out of my day to show other folks how to do something or perhaps as a team we stop to talk about a solution? Maybe then we won't waste too much time duplicating efforts or missing learning opportunities.

I fear that it is often that we, as engineers, forget that we are working as part of a bigger system. While our day to day tasks may be engineering the bigger picture involves quite a bit of peopleware. Pace is relative, work together with your teammates, and you are collectively fast.

Data

Let's talk about data. Data is obviously important for a lot of decision making. I mean this in the aspect of both running and software engineering. This one bit is actually one of the aspects of software engineering that has actually made me a better runner, but also still a better engineer.

Quick story time; flashback to my first ever half marathon. It was the Staten Island Half Marathon. I had trained for it, but I had convinced myself that I could run a qualifying time for the NYC Marathon.

Spoiler alert: I didn't make that goal. But if I looked back on my data for my training that led up to this race, I would've already known that my goal wasn't realistic. I did not come close to the right pace I needed to be at in any of my training runs and I should have acknowledged that before committing to attempting that pace during a race.

So how did that race go? Well, I went out hard at the pace I needed to be and well, I didn't make it all the way pacing that fast. I will just say that I finished a good ~17 minutes slower than where I wanted to be.

So what did I learn from all of this? Know your data and know it well. For most of my important training runs, I take a look at the data (Strava) and get a good gauge on how my training is going. I'll constantly make adjustments to make sure I'm headed in the right direction.

Feedback is data; remember that. Think about software projects; are you constantly learning about your progress? I can tell you that, it's a lot easier to pivot earlier on than when you have already built something and invested a lot of engineering time and effort. If you are practicing agile methodologies and have done waterfall in the past, you can probably relate! Ask for some feedback from your stakeholders, whomever they may be (your manager, your tech lead, designer, PM, et cetera). Those fine tuning knobs are there for you to adjust and make everyone more efficient.

Long Term Goals

It's not a sprint, it's a marathon. Yes, let's just get that saying out of the way now; it is a very valid statement though. At the time of this writing, I am happy to say that I have successfully completed five marathons. But getting to this level, did not happen overnight. I recall when I first started out running, the amount of soreness I had from just a 5k (~3Mi) jog. It was prety painful and awfully tough. But after a while, my body adjusted and I had become accustomed to what works and what doesn't for my running.

Do you know what that sounds like though? That sounds exactly like my engineering career. When I first started I was scared, anxious, insecure, but also just willing to put in the effort to make those feelings less amplified. Note that I say less amplified because I will be honest, that there are some times to this day, that I will still have those feelings.

Consider a a new big project that you promise to deliver; the project as a whole may seem quite large and overwhelming, but if you break things down and focus on pieces of the whole little by little, it's just so much easier to absorb. So, whatever you may be working on, whether it may be training for a race of any distance or building out an application of any size, remember that there is always a finish line and you can get there little by little.

By Adrian Cruz | Published March 30, 2019, 9:55 p.m. tags: engineering, running, software engineering