People occasionally ask why this blog covers both engineering and running. The question implies they are separate topics that happen to belong to the same person.

My view is different. They are instances of the same underlying problem: how do you build systems that improve steadily over time?

The shared structure

Both software engineering and distance running are disciplines where:

  • Short-term results are a poor measure of long-term progress
  • Consistency over long periods matters more than peak intensity
  • Good fundamentals compound; bad habits also compound
  • You cannot shortcut adaptation — in training or in skill development
  • Feedback loops are essential, but not all feedback is signal

When I think about how to structure a training block, I use the same mental model I use to think about technical projects. What is the current constraint? What would sustainable progress look like at this rate? Where is the feedback loop weakest?

The danger of optimization theater

In engineering, this looks like building a sophisticated monitoring setup for a product nobody uses yet. The work feels productive. It is not.

In running, this looks like analyzing heart rate zones daily while averaging 25 miles per week. The tracking feels productive. The training load is too low to matter.

Both are forms of optimization theater — doing the visible parts of good practice without the unglamorous underlying work.

What I have learned from each that applies to the other

From running: Aerobic base development takes months of boring, slow work before it pays off. Software skill development works the same way. The engineers I find most technically credible have spent years reading deeply and building things nobody will ever see.

From engineering: Systems need feedback loops to improve. Vague running goals (“get faster”) produce vague results. Measurable, bounded goals (“run a sub-1:45 half marathon by October”) create feedback.

Why this matters for how I write

I am not trying to write a productivity blog. I am not interested in “10 habits of high performers” content.

I am interested in the actual mechanics of building systems that work. In code, in training, and in the habits that support both. That is what this blog is for.