TITLE: Too Many Variables
AUTHOR: Eugene Wallingford
DATE: July 06, 2005 8:23 PM
DESC: In which I think through a seemingly-failed workout to both uncover the problem and realize that it shouldn't have been so hard to do so.
-----
BODY:
Do you remember
this old Billy Crystal/Christopher Guest skit
from
Saturday Night Live?
The guys were janitors. When they ran into one
another, they would take turns describing to one
another accidents that had happened to them. The
first incidents in the exchange were the sort that
could happen to a working guy, such as "You know
when you're working in the shop and you hit your
thumb with a hammer?" But as the skit progresses,
the accidents become incidents of strange, self-inflicted
pain that could never happen accidentally, such as
"You know when stick your inside your car door and
just slam the door right on your head? That really
hurts." The unforgettable catch phrase of the skit
was this classic: "I *hate* when that happens."
Interval training
on a track can be like that. I imagine most non-runners
listening to me tell tales of my track work-outs and
thinking of me the way we all thought of Guest and
Crystal at the end of their skits. "I *hate* when that
happens." Well, duh. It's all quite funny, unless
your the guy with his head crushed by the car door.
When I run intervals, or repeats, I am trying to work
my body at the edge of its capabilities. As a result,
there is little margin for error or unexpectedness.
When things don't go as well as expected, the workout
can feel something like slamming a car door on my head
-- voluntarily, at 5:30 or 6:00 in the morning. I hate
when that happens.
Doing my 6x1200m workout this morning, I re-learned
what all good experimental scientists know: too many
free variables make it difficult to know why what happened
happened when what happened isn't what you expected.
What happened? I came up way short today. I was trying
to run each repeat in 4:52 or less. The first was tough
but right on mark. The second slowed down by 3 seconds
and felt bad enough that I decided to jog lightly through
the third. When I ran the fourth, I slowed down another
2 seconds and realized that I was going to be able to
meet my goal for the day. In place of the fifth and sixth
repeats, I chose to alternate faster laps with slower
ones, in hopes of not turning the day into just another
slow jog.
But why did this happen? Here are some possibilities:
- I tried to do too many repeats.
- I tried to run each repeat too fast.
- I ran too short a recovery period in between repeats.
- I wasn't ready to run my repeats outdoors on the
400m track just yet.
- My repeats were too long because I was not running
the inside lane of the track.
- I am still feeling lingering effects of my
recent half marathon,
two hard workouts last week too soon after the half,
and a moderately fast 14-miler on Sunday?
Running outside itself wasn't likely the problem, though
the nature of the feedback is different. Attempting six
repeats wasn't likely the problem, either, because the
problem wasn't with Repeat 6; it was Repeat 3, or even #2.
I think the most likely explanation is the combination
of three variables. First, my legs are still tired
from last week. Second, I tried running 400m recoveries
instead of the more ordinary 600m (50% of the repeat
distance). I will try to remedy those next week.
Finally, and perhaps most important, I now realize that
I was running repeats longer than 1200m. Last week's
4:53 repeats were right at my target distance, because
I was running to lane markers on the indoor track. This
morning, I was running three laps in Lane 4 of the 400m
outdoor track. Four laps in Lane 4 is actually about
1.05 miles, so my three laps work out as a little over
1266m. That extra 66m is enormous when it comes
to running at my limits. To do my target 1200m pace, I
should have allowed myself an extra 16 seconds on each
repeat!
The idea that my laps were longer than planned didn't
occur to me at all until I was out on the track, slogging
through laps, asking myself, "But why?" I *hate* when
that happens.
I should have taken the feedback from my body at face
value and adapted my pace. Whatever the reason, I was
not going to be able to do 1:37 laps, so I should have
eased off to a pace that I could sustain. Instead, I
despaired a bit and gave up on a couple of the repeats.
Note to self: Feedback is good; use it to get better.
Multiply these three factors together, and you get a
workout that does not go as planned.
Then again, in retrospect, maybe my times weren't so
bad after all. After crunching the numbers, I think
that I can safely conclude that I was simply trying to
run too fast.
Unfortunately, things don't usually turn out so tidily.
Ordinarily, I wouldn't know for certain the reason that
the workout that did not go as planned, because I put
too many variables into play. What I don't want to do
is use my good fortune this week as rationalization for
making the same mistake next week.
My excuse, er, reason, for changing so many things at
once is that training time is precious. From last
Sunday, I had exactly 13 weeks until the
Twin Cities Marathon.
If I hope to meet my race goals, I need to make steady
and rapid progress in my workouts.
That is just the sort of reason that we software
developers use to convince ourselves and our clients
that we need to shove more and more features into the
next release. It's the same excuse that teachers tell
themselves and their students when they try to squeeze
just one more topic into the already crowded
syllabus of a course. The results are similar, too.
The developers and instructors often fail to achieve
their goals; software clients and students are left
holding the bag. And then in the end, we are left
asking ourselves why.
Of course, this morning's experience also taught me
another lesson: do my homework better when it comes to
computing repeat distances on the track. "Do your
homework" is, of course, also a fine piece of advice
for software developers, software clients, teachers,
and students alike. :-)
-----