The runner's discipline and the programmer's
Running a marathon and building software are the same mental battle.
At 5:30 in the morning, when the alarm goes off and the body asks for 5 more minutes, the decision is already made. Not in that moment — it was made the night before, when I laid out the clothes. It was made the week before, when I set the plan. It was made months ago, when I decided to run a marathon in under 4 hours.
Discipline isn't willpower. Discipline is removing the decision. When you have to decide every morning whether you're going to run, eventually you'll say no. When you've already decided and you only execute, the question disappears.
The parallels nobody sees
Building software and training for a marathon look more alike than any programmer or runner would admit:
- Both demand consistency over intensity. Running 30km one day and not running for a week injures you. Programming 14 hours on a Saturday and not touching code for 5 days sets you back. What matters is frequency, not the peak.
- Progress is invisible day to day. You don't see improvement between Tuesday and Wednesday. Or between one commit and the next. But in 3 months, you look back and everything has changed.
- Pain is part of the process, not an error. Muscles ache. Bugs frustrate. If you wait for a path without pain, you'll never start.
- The plan matters more than motivation. Motivation is gasoline — it runs out. The plan is the engine. A training plan tells you what to do when you don't want to do anything. A well-defined architecture tells you what to program when you're lost.
What running taught me about code
I started running seriously a year ago. The first 5 kilometers were the hardest of my life — not because of the distance, but because of the shame of being bad at something. I'm used to being competent. In code, in data analysis, in my work. But in running, I was an absolute beginner.
That humility carried over to my code. I stopped assuming my first solutions were the best ones. I started treating the first draft as what it is: a first kilometer. Slow, clumsy, necessary. The final version comes after iterations, not inspiration.
There's no perfect code on the first try, just like there's no perfect marathon without months of imperfect kilometers.
Sub-4h: the goal that organizes everything
My target for November 2026: run a full marathon (42.195 km) in under 4 hours. That means holding an average pace of ~5:40/km for nearly four hours straight. It isn't elite, but for someone who a year ago could barely run 5km without stopping, it's a radical transformation.
The Sub-4h goal isn't only about running. It's an organizing principle. It defines my food, my sleep, my stress management, my weekend agenda. When everything in your life points toward a clear target, daily decisions get massively simpler.
The same thing happens in software. When you know exactly what you're building and why, every technical decision aligns. Do we use this library or that one? Depends — which one gets us closer to the goal? Without a clear goal, every decision becomes an infinite philosophical debate.
Kilometer 35
Experienced runners talk about kilometer 35 as the moment where everything breaks. The legs stop cooperating. The mind invents reasons to stop. The body says it's been enough.
In programming, "kilometer 35" is that phase of the project where the initial excitement is gone, technical problems pile up, and the deadline is closing in. It's where most people give up or ship something mediocre.
The ones who cross the finish line — in running and in code — are the ones who learned to keep going when it stopped being fun. Not for the masochism. Out of commitment to a version of themselves that doesn't yet exist but they're building, one kilometer at a time, one commit at a time.
If you're starting something and you're terrible at it — keep going. Being terrible is the entry price. What comes after is worth it.