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: 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. :-) -----