Athletics

I was never the most talented gymnast, and dealing with that was difficult. I had to fight for a place in every competition lineup. Because I didn't compete on all six events, there was no guarantee I would compete at all. If I didn't make the lineup on the events I trained, I couldn't count on another event to get me into the competition.

That uncertainty was part of the work. I had to keep preparing without knowing whether I would get the opportunity to show it. Earning a spot mattered to me because I knew how much had gone into being ready for it.

I had constant ankle issues. The pain made it difficult to continue, and learning how to recover meant accepting that sometimes I needed to take a step back. Ice baths, rehab, and nutrition became an important part of how I trained and came back stronger.

The small things were just as important as the big things, sometimes more. They weren't always satisfying in the way that landing a skill or competing was. But even when I couldn't train the way I wanted, there was still something I could do to help myself recover or support the team. Progress also depended on the work that happened outside the routines.

There are six events in men's gymnastics, and some didn't play to my strengths. I struggled with certain events, and continuing to spread my effort across them also meant exposing myself to injuries in areas where I wasn't contributing my best.

Choosing a specialization gave me a way to be more deliberate. I could reduce those injury risks and put more of my training into the events where I could help the team most. It was a decision about where I could make the strongest contribution and give myself the chance to do what I did best.

As vault leader, I built the training plan and tried to lead by example. Following through on the plan was part of that responsibility. I couldn't expect consistency from other people if I wasn't showing it myself.

One of the biggest things for me was never skipping out. If I found an excuse to avoid the work, other people could use that as a reason to do the same. The standard I set in ordinary practices mattered because teammates saw what I actually did, including when there wasn't a competition immediately in front of us.

Building the training plan also meant listening. Teammates had their own opinions, injuries, and limits, and I needed to account for those. Vault is explosive, and fatigue can lead to unexpected injuries. What made sense in a plan could change depending on how someone was feeling that day.

My own ankle issues made the importance of recovery clear to me. As a leader, I had to make room for other people to tell me what they needed and adapt the training around that. Taking the work seriously included knowing when the plan needed to change.

I was the person people counted on for a stuck landing. We usually tried to compete on vault first, and I was the person they put up last on that first event. Finishing the vault lineup strongly helped give the team a good start to the competition.

Momentum mattered at the start of the meet and within each event. A strong finish could help teammates gain back confidence after mistakes earlier in the lineup. Going last meant I had an opportunity to help the team move into the next event feeling better. That gave my routine a purpose beyond my individual result.

The biggest thing I took from gymnastics into software engineering is focus. Working through a difficult technical problem can take hours of sustained attention. That process feels familiar to me: in gymnastics, I had to understand how individual movements and muscle actions fit together to produce a skill. Often there was one missing piece preventing my body from moving the way I wanted.

For example, a tumbling pass might end in a short landing because I didn't raise my arms enough at takeoff. Understanding the landing meant working back through the movements that led to it. After every attempt, I thought through what happened, which movement was off, and how it affected the rest of the skill.

Debugging calls for a similar kind of attention. For example, a dependency resolver following A to B to C and back to A can exhaust the call stack if it never detects the cycle. Tracing the active dependency path reveals where the repeated calls begin; tracking that path lets the resolver detect and report the cycle. In both situations, understanding how the pieces interact helps me find the adjustment that changes the outcome.

I had to unlearn brute force. Repeating the same attempt and hoping it would work better wasn't always helping me progress. The effort was there, but I still needed to understand what was going wrong. Sometimes the most useful thing I could do was take a step back and rethink the approach.

That matters in software engineering, too. I need to understand why an implementation is failing before deciding what to change. Gymnastics taught me both how to stay focused and when another attempt needed to begin with a different idea.