Running and Engineering: Why They Are the Same Thing

Both Are About Solving Problems With Data

In engineering, when something is slow, you profile it. Look at the metrics, identify the bottleneck, fix it. Running is identical. When your 10K time stalls, you look at the data — training volume, pace distribution, heart rate trends — and make changes. This site exists because of that mindset. Pull all the Strava data, build dashboards around it, spot patterns.

Iteration Over Revolution

Good engineering is not about rewriting everything from scratch. Small, incremental improvements — refactoring a function here, optimising a query there. Running works the same way. You do not suddenly PB by changing everything. Add one speed session per week, increase the long run by a kilometre, and the gains compound over months.

The 10K went from 50 minutes to 41:15 over nine years. Not a revolution. Hundreds of small iterations.

Monitoring and Observability

Every good system has monitoring. Watch for errors, track latency, set up alerts. As a runner, your body is the system. Heart rate is CPU usage. Pace is throughput. Fatigue is error rate. Learning to read these signals — and knowing when to back off before something breaks — transfers directly from on-call engineering to marathon training.

The Importance of Recovery

In engineering, you do not deploy on a Friday. You give systems time to stabilise. Running is the same — the adaptation happens during recovery, not during the hard session. Easy runs are system downtime. Sleep is your maintenance window. Skip them and the system degrades.

Debugging Your Running

When a race goes badly, treat it like a production incident. What happened? What were the conditions? What did the data say? Pacing issue, nutrition issue, or training issue? This retrospective approach has improved running more than any single workout. Engineers make good runners because we are trained to ask why, not just accept the outcome.