C Flat

My first blog unexpectedly converged with cycling yesterday. That is, I experienced an unexpected flat tire (is there any other kind?) on my ride and the event unexpectedly became the foremost topic for my blogging debut.

Amazingly, I've never had to change a flat tire in the thousands of miles that I've surely ridden in my life. Not from my Viper days of endless summers riding-n-jumping anything that presented a glimpse of hope that I'd catch over a foot of air. Not from my StumpJumper days of driving an hour to some mountain pass to catch some singletrack where I was sure I wouldn't see another human. And not even from my days at CU-Boulder where my bike was the only vehicle I had but still disregarded it enough to leave it under a winter of snow.

No, not at any point during those times. And so I've never had the chance to abstract from the experience (and, after all, it was only a flat tire). But there are some correlations between dealing with a flat tire and say, dealing with a hardware failure or software defect.

Lesson #1: Don't panic.
Dealing with a flat tire obviously begins the moment you notice you have a flat. If that's on a downhill run when you're clocking over 27 mph, it's best to keep your head and calmly stop the bike. Dealing with a critical bug in an application is the same. It's best to stay calm in the face of panic that sometimes ensues from important customers communicating their disappointment. Sometimes important information is lost in panic at a critical time: your cadence magnet fell off somewhere in the past 50 yards, or, exactly who was doing exactly what on the system when this exact problem was first discovered?

Lesson #2: Clear your mind.
Take a deep breath. Gather your senses. Focus on the problem at hand.

Lesson #3: Be prepared.
The items I hauled on every ride and figured I'd never use were my saviors.
Things that saved me: saddle bag, extra bike tube stored in plastic bag, tire levers, and CO2 inflation system air chuck with CO2 canister.
Things that didn't have a chance to save me: cell phone left on the kitchen counter.

Luckily I had read about how to change a flat. Actually practicing it at some point before I took my bike out would have been better. I think that anyone who's ever had a vested interest in hardware disaster recovery understands that this is critical. And also in software, select the best tools for your bag and know them.

Lesson #4: Find beauty in the situation.
Stopping and taking in a 360 degree view of the horizon yielded a deep appreciation for a first Colorado spring day, gorgeous mountain views, and for how utterly alone and dependent on my own competence I was.

Lesson #5: Buy yourself time.
One canister of CO2 shot into a new tube is enough to get you back on your bike and back to home base. Take it. Don't make the situation potentially more disastrous by pushing it. Dealing with a critical software defect is oftentimes the same; get a patch out as soon as possible that addresses the issue. Then start work on a permanent fix that addresses the root cause and write comprehensive unit tests to ensure the problem never surfaces again.

Lesson #6: Debrief.
Time to reflect and communicate. If my son were a little older, I could have talked to him about these lessons I've learned that have been reinforced. I could show him how to change a flat tire. I need to take inventory of my saddle bag and replenish the supplies I used before my next ride.

In software this is sometimes mistaken as assigning blame... that's another blog. In some cases, we may have discovered a systemic problem with some implementation that we need to communicate to all developers. Or we may have touched on an organizational challenge like QA resources.

In any case, I believe this lesson is critical to doing your job better tomorrow than you did today. This time I changed the flat tire. To be sure, next time I'll change the flat tire in no time flat.