« Horseshoes & Hand Grenades

“Close only matters in horseshoes and hand grenades,” I first heard from my grandpa many years ago. Many things are binary, true or false, complete or not-complete. Almost completing a task is the same as not completing that task. There is no gray area, and stop letting yourself think there is. It seems like a pretty harsh sentiment but I think there are real lessons to learn from thinking this way.

Analogy time: think about completing things in terms of a marathon. In a marathon you run 26.3 miles. There’s a start line and an finish line. If I run 12 miles, and my legs give out, I did not run a marathon; I ran 12 miles and failed. If I run those same 12 miles, pass out, get some food and finish the marathon, then I ran a marathon. Every day I train, I’m working towards being able to run a marathon. That progress is all moot if I never run the marathon. Each mile during a marathon, every minute put towards that race is only progress if I complete it.

This applies to software projects as well. Working on code for hours then never committing your code is not progress. It might be fun for your brain or it might help you find new solutions, but that’s not necessarily progress towards your ultimate goal. Opening a pull request isn’t progress. If the pull request results in a discussion that ultimately results in a definitive answer, it could be considered progress. Opening pull requests without ever making a decision about them is like constantly training for a marathon you never intend to run.

There’s a few ways to train yourself to efficiently work towards your goals. (what is this? talk in the intro about what exactly we are getting at, why progress is important)

Work on tangible things

You should be able to quickly grok your goal and know exactly what it is with all its caveats. Something like “I will be able to run a marathon in under 4 hours” is great, but not “train for a race.” What race? How far is the race? Am I running? Biking? The definition of what you’re working towards is one of the most important things; it defines your progress, failure, everything.

Have a timeline

Goals can’t go on forever. The timeline is there to help you push yourself a bit, evaluate if you’ve succeeded or not and adjust your future goals. Without a timeline you’re just lying to yourself about what you’re “focusing” on.

Be realistic

In order to be realistic I try to find a baseline goal to understand the status quo like “run 10 miles this week.” Knowing that I can do that, stretch a bit and plan to run 13 miles next week. Understanding the baseline allowed me to decide if I should push on further or if I should keep trying to be successful at 10 miles.

Evaluate

Use the basic guidelines you setup for your goal to measure whether or not you’re successful, or heading towards success. Once a goal is set I like leave it there until the end-date to keep progressing towards it, but if you evaluate and you’re clearly going to fail, maybe re-evaluate your goals and priorities then and there.

Failure is ok, but move on

Admit failure when it happens, doing so allows you to move on and try again, maybe being more realistic. Its not the end of the world, but clearly something needs to change to be successful next time.

People have been saying a lot of these things for years now. I remember hearing some of this in High School and thinking it sounded silly to even talk out-loud about, because “duh.” For me, though, I thought a lot of it was obvious when someone said it, but once I actually applied some of this to how I think about work and personal goals I felt the difference. At least now I’m starting to get a clearer understanding of my abilities and can make smarter decisions about my personal priorities in life.

EVALUATE/DELETE

A few years ago I decided to train for and run the Minneapolis half marathon. So I Googled half marathon training and landed on Hal Higdon’s guide. I lined up my calendar to finish my training on the correct day, picked up a pair of Saucony shoes for distance running and off I went. Over the following three months, I spent much of my time keeping up with the training schedule. I did pretty well, if I do say so myself. On the day of the race I had a friend drop me off near the start-line just a few minutes before the gun. Standing at the start line for a longer race is really pretty energizing. It’s hard not to ponder the work you’ve put in in the last few months, and everyone else is feeling the same way. There’s a lot of excitement. A few minutes go by, then another 10, then 15. About half an hour after the race was supposed to start Team Ortho, who runs a lot of local race events, cancelled the event due to the looming storm. This storm was apparently particularly alarming for this race due to the close proximity of the Mississippi river to the route. Well crap, months of training and a lie of a participant T-Shirt.

Shortly after this failure of a half-marathon, some friends convinced me to direct my training towards a Full marathon. Some re-jiggering of the training schedule, find some new routes and back on track. As the training schedule became more difficult to fit into a day so did my work schedule. One thing led to another and I wound up injuring myself a few weeks before the race. I screwed myself this time. I didn’t end up running the race. Yet again, months of training and I was still not a Marathon runner. 

There’s no such thing as an almost-marathoner. There’s just people who’ve run marathon and people who haven’t. In terms of marathon races its more or less a badge of honor to be able to say you’ve done it. You endured that work and felt the pain and excitement of that journey. There are stages to the journey you need to take though. Let’s think about this in terms of a software project: my code is finished, mark it as complete. Something’s wrong though. 

/end with becoming a marathon runner