What actually eats most of your programming time?

For the last few months, I’ve been paying closer attention to how I spend my programming time and I’ve been trying to answer one simple question:

What task or problem eats the most time?

The more I paid attention to what I was doing, the more I noticed it wasn't high-level planning or deciding whether to progress an athlete or pull-back.

It was rebuilding things I’ve already built!

Writing a week without a well-defined mesocycle or template immediately turns it into a crippling blank-page exercise. Then I find myself trying to invent a new week layout or progression for a problem I’ve already solved dozens of times. Sometimes this is because the solutions I've built aren't organized well enough to find and sometimes because I'm focused getting the week layout right rather than building the actual week.

The physical process of building the program often takes significantly longer than deciding what the program needs to accomplish.

Reading an athlete’s feedback, understanding how they’re adapting, and deciding whether to continue progressing, back off, or make a structural change takes time. However, that’s also the part of the coaching process where we deliver the most value to the people we're guiding, so I'd rather focus my time there than re-typing the same solution to a problem over again.

The distinction I keep coming back to is this: Individualized coaching doesn’t require inventing a new solution every week.

It requires:

A well-defined plan
A library of proven progressions
Clear rules for selecting and adapting them
Enough attention to athlete feedback to know when the plan needs to change

Interestingly, I looked back through several of my mentorship conversations, and this same problem appeared over and over again. The most common recommendation I’ve made to other coaches is to stop programming from a blank page and start building a searchable library from the work they’re already doing. Write it once, save it in a place you can access it again, organize it, then adapt it for a client's unique situation.

I’m curious whether the same pattern shows up for other coaches.

For those of you who write individual programming, do a quick audit:

Which task takes most of your programming time: deciding, building, reviewing feedback, or revising?
What do you repeatedly rebuild from scratch?
What part of your process would you never want to automate because it represents the actual coaching?

Drop your answers below. I’m interested to see where our programming time is really going.

8 comments

What actually eats most of your programming time?