What Marathon Running Taught Me About Shipping Software
Lessons from 21.1 kilometers of pavement in Tel Aviv — and how they apply to building products that don't suck.
Published: March 16, 2026
Reading time: 5 minutes
Tags: productivity, consistency, systems, lessons
The Parallel Nobody Talks About
I've run three half-marathons in the last few weeks. I've shipped a dozen software projects.
Here's what nobody tells you: The same principles that get you across the finish line at kilometer 21 are the ones that get your product to launch day.
Not metaphorically. Literally the same principles.
Lesson 1: Consistency Beats Intensity
Running
What doesn't work:
- Run 15km once, then take a week off
- Sprint intervals every day until you're injured
- "I'll start training next month" (repeat for 6 months)
What works:
- Run 5-6 days per week, even when it's boring
- Most runs are easy pace (conversational)
- One long run per week, gradually increasing distance
The boring truth: Marathon training is 80% easy runs at a pace you could maintain while chatting.
Software
What doesn't work:
- Code for 16 hours, burn out, disappear for a week
- Rewrite the entire codebase in a weekend
- "I'll ship when it's perfect" (never ships)
What works:
- 2-3 hours of focused work per day, every day
- Most commits are incremental improvements
- One significant feature per week
The boring truth: Successful projects are 80% small, unsexy commits that move the needle slightly forward.
The insight: Your body (and brain) adapts to consistent stress, not sporadic intensity.
Marathon training plan: 6 months, 6 days/week, 40-60km/week
Software project: 6 months, 5 days/week, 10-15 hours/week
Both beat:
- 2 weeks of all-out effort → burnout → quit
Lesson 2: Measure What Matters (And Ignore the Rest)
Running
Metrics that matter:
- Weekly distance (km/week)
- Long run distance (increases weekly)
- Resting heart rate (fitness indicator)
Metrics that don't:
- Pace on easy runs (doesn't predict race performance)
- What shoes other runners wear
- How many Instagram likes your running photo got
The trap: Obsessing over daily pace → running too fast → injury → can't train.
Software
Metrics that matter:
- User retention (do they come back?)
- Time to value (how fast can they get value?)
- Core feature usage (are they using what you built?)
Metrics that don't:
- Lines of code written
- How many stars competitors have on GitHub
- What framework is "hot" on Hacker News
The trap: Obsessing over vanity metrics → building features nobody uses → product dies.
The insight: Focus on leading indicators (input), not lagging indicators (output).
Marathon:
- Leading: Did I run 50km this week? ✅
- Lagging: Will I finish in under 4 hours? (can't control on race day)
Software:
- Leading: Did I ship 3 features this month? ✅
- Lagging: Will users love it? (can't force)
Control the input. Trust the output will follow.
Lesson 3: The 80% Rule (Don't Optimize Too Early)
Running
Beginner mistake: Buy the most expensive running shoes, GPS watch, heart rate monitor, compression socks, energy gels...
Result: $500 spent, still can't run 5km.
Better approach:
- Start with decent shoes ($80)
- Run until you can do 10km consistently
- Then optimize (if needed)
Why: You don't know what you need until you've done it for 3 months.
Software
Beginner mistake: Set up microservices, Kubernetes, CI/CD pipelines, infrastructure as code, monitoring dashboards...
Result: 3 weeks of DevOps, zero users.
Better approach:
- Deploy to Railway/Vercel ($0-20/month)
- Ship v1 to real users
- Then optimize (if needed)
Why: You don't know your bottlenecks until you have users.
The insight: Premature optimization kills momentum.
Marathon:
- First goal: Finish (just finish)
- Second goal: Finish comfortably
- Third goal: Finish fast
Software:
- First goal: Ship (get it to users)
- Second goal: Ship reliably (fix critical bugs)
- Third goal: Ship fast (optimize performance)
Most projects die at stage 1 because they tried to optimize for stage 3.
Lesson 4: Pain Is Information, Not a Stop Signal
Running
Kilometer 18: Your legs hurt. You want to stop.
Two types of pain:
- Muscle fatigue: Normal. Push through.
- Sharp knee pain: Injury. Stop immediately.
The skill: Learning to distinguish signal from noise.
Software
Week 6 of a project: You're tired. The code is messy. You want to quit.
Two types of pain:
- Implementation fatigue: Normal. Keep shipping.
- Fundamental architecture problem: Serious. Stop and refactor.
The skill: Learning when to push through and when to pivot.
The insight: Discomfort is not always a reason to quit.
Marathon:
- Tired legs at km 30? → Normal, push through
- Can't feel your foot? → Stop, injury risk
Software:
- Tedious bug fixes? → Normal, push through
- Codebase is unmaintainable? → Stop, refactor
Experience teaches you the difference.
Lesson 5: The Long Run Teaches You What Daily Practice Can't
Running
Daily runs: Build base fitness, get faster, practice form.
Long run (30-35km): Teaches you what your body does when glycogen depletes, how your mind behaves at km 32, what gear causes chafing at km 25.
You can't learn this from 10 short runs.
Some lessons only come from sustained effort.
Software
Daily coding: Build features, fix bugs, improve skills.
Month-long project: Teaches you what happens when tech debt compounds, how motivation behaves in week 4, what decisions cause pain at scale.
You can't learn this from 10 side projects.
Some lessons only come from shipping something real.
The insight: Some knowledge requires endurance, not repetition.
Marathon wisdom that only comes from the long run:
- How your body feels at km 35
- When to take energy gels (km 20, 30, 35)
- Mental strategies for the last 10km
Software wisdom that only comes from sustained projects:
- How tech debt accumulates (invisible at week 1, crippling at week 10)
- When to refactor (before it blocks new features)
- Mental strategies for late-stage motivation
Short sprints teach tactics. Long efforts teach strategy.
Lesson 6: Race Day Is Just Another Training Day
Running
The myth: Race day is special. You'll run faster because of adrenaline.
The reality: You run exactly as well as you trained. Adrenaline helps for 5km, then your training takes over.
The trap: Undertrain, rely on race-day magic → crash at km 30.
Software
The myth: Launch day is special. You'll fix bugs faster because of urgency.
The reality: You ship exactly as well as you practiced. Urgency helps for a day, then your habits take over.
The trap: Ship broken product, rely on launch-day heroics → burnout at week 2.
The insight: Performance under pressure equals your preparation, not your intentions.
Marathon:
- Train at 5:30/km → race at 5:30/km (maybe 5:20 with adrenaline)
- Train at 6:00/km → race at 6:00/km (adrenaline doesn't last 42km)
Software:
- Ship clean code in dev → ship clean code in prod
- Ship spaghetti in dev → ship spaghetti in prod (deadlines don't improve code quality)
You don't rise to the occasion. You fall to your level of training.
Lesson 7: Quitting Is a Luxury (Until It's Not)
Running
Kilometer 38: Everything hurts. You could stop. Nobody would judge you.
But you don't. Because you trained for 6 months for this.
The commitment made in training carries you through the race.
Software
Month 5 of a project: Motivation is gone. You could quit. Start something new.
But you don't. Because you already invested 5 months.
Sunk cost fallacy? No. Commitment made when you started carries you through.
The insight: Finishing is a habit, not a decision.
Marathon:
- You practice "not quitting" on every training run
- Long runs teach you that discomfort is temporary
- Race day is just the final exam
Software:
- You practice "not quitting" on every feature
- Month-long projects teach you that mid-project slumps are temporary
- Launch day is just the final exam
People who finish marathons aren't tougher. They just practiced not quitting.
The Meta Lesson: Systems Beat Motivation
Marathon training is a system:
- Monday: Rest
- Tuesday: Easy 8km
- Wednesday: Intervals
- Thursday: Easy 10km
- Friday: Rest
- Saturday: Long run (progressive)
- Sunday: Easy recovery
No decisions. Just execute.
Software projects need the same:
- Daily: 2 hours focused coding (same time, same place)
- Weekly: Ship 1 feature (however small)
- Monthly: Reflect + adjust roadmap
No relying on motivation. Just execute.
The truth both domains teach:
Motivation is what gets you started.
Systems are what keep you going.
My Current System (Tel Aviv, March 2026)
Running:
- 6 days/week, 50-60km total
- Long run: Saturday morning, 6:00 AM (before it's 30°C)
- Next race: Tel Aviv Marathon, April 2026 (targeting sub-4 hours)
Shipping:
- Code: Mon-Fri, 7:00-9:00 AM (before meetings)
- Write: Sundays (blog posts, documentation)
- Ship: Every Friday (deploy something, even if small)
Both follow the same principle: Show up, do the work, trust the process.
Summary: The 7 Lessons
- Consistency beats intensity — Daily progress > occasional heroics
- Measure what matters — Focus on inputs, not vanity metrics
- 80% is enough to start — Don't optimize before you've shipped
- Pain is information — Learn to distinguish discomfort from disaster
- Long efforts teach unique lessons — Some wisdom requires endurance
- Performance = preparation — You fall to your level of training
- Systems beat motivation — Build habits, not hype
Both marathons and software are endurance sports.
The winners aren't the fastest or smartest.
They're the ones who show up every day and don't quit.
Currently training: Palestine Marathon, May 2026. Follow the journey on Strava or Twitter.
Currently shipping: dev-diary, CENTAUR projects, AI intelligence tools. Follow progress at patrick.technology.
Written at kilometer 15 of a long run. Had to stop and type this on my phone. The irony is not lost on me.
Get Updates
New posts on systems thinking, AI, and building things. No spam, unsubscribe anytime.