On Not Starting

On Not Starting

Here’s one of those ADD self-assessment questions:

“Do you have a tendency to start projects and not finish them?”

My gut answer is NO, that isn’t a problem for me. The reason it is not a problem is because I don’t START the projects in the first place unless I have a reserve of energy to initiate them. I’m also fairly comfortable with projects that are “in-progress”, which isn’t the same as “unfinished” in my book.

Perhaps, though, from the perspective of people who believe in projects having a concrete starting and ending point, that my answer would actually should be “YES”…hmm.

My Relationship with Challenges and Resistance

It’s true that there are times when I wish I could resolve troublesome challenges faster, because I tend to not even start them because I associate unpleasantness and unbounded inconvenience/uncertainty with them. I am the kind of person who buys an automatic cat litter box. I loath recycling because I find the task of cutting/flattening boxes and getting them into my car really irritating, because everything falls out and the recycling dumpster is always sticky and full unless I go on Wednesday, which means I have to remember to time it right, which imposes a mental burden on me that I think is stupid. Such details weigh on me greatly, more than I think they should, but the reaction is automatic. I have to expend a lot of willpower to get through it.

Such is the case even with projects that I do think are worthwhile. Building a new website with flashy new bits? That’s worthwhile because it reflects well on me, makes it easier to publish my own work in a visually-compelling way, and there are business benefits too. I already know HTML/CSS, and Javascript, and know how to use the thousands of dollars of professional computer graphics production tools at a high level of competence. The hard part for me, though, is dealing with my poor attitude toward HTML/CSS, which I think are poorly designed languages constructs invented by people who never had to do production interaction design. And don’t get me started on Javascript’s weird design flaws. On top of my poor attitude, there’s the ACTUAL hard work of learning concepts associated with other people’s tool libraries (often poorly documented), inventing new concepts to fill in the gaps, and then doing the meticulous incremental work to tie everything together step-by-step. The time it takes to conceive of an ideal system takes a few minutes, and it is like flying. Taking the same number of minutes to do the step-by-step incremental work, by comparison, will me through half a paragraph of someone’s terrible documentation, leaving me with more confusion until I suddenly realize what’s missing and fill in the conceptual gaps. It will take many more minutes to get to the point where I see my new understanding reflected in working code, and I don’t find this process particularly enjoyable as other programmers would. I just am drained and a little angry about it. It’s necessary work, and I totally believe in doing it, but because my attitude is so poor toward it I am never exactly in the mood to start it. That’s where I need to draw on my reserve of willpower, which is essentially my ability to deal with BS before my brain just shuts down and refuses to move anymore.

There are, of course, projects where I don’t experience such resistance. Cooking is one of them, though now that I think about it I do have a resistance to collecting all the ingredients for my mise en place and doing dishes afterwards. Having to clean the kitchen and clear-off counter space is a resistance that I have to overcome. Peeling and chopping vegetables I don’t enjoy. I don’t like measuring ingredients or looking up recipes, so I tend to rely on intuition and taste. I will spend time testing principles like cooking meat to precise temperatures, understanding how to make a decent roux, and timing how long it takes to get a pan up to temp so I can get a good brown going. Trying a NEW recipe or technique is where I face the most resistance, because I have to learn and internalize a number of new ideas that contribute to the success of the preparation. This is why I love magazines like Cook’s Illustrated, which outline the principles behind excellence so I have a useful metric to apply in my cooking. That transforms the experience into an edible experiment, harnessing all my powers of observation.

The Need for Speed

You know, perhaps it’s the feeling of harnessing ALL my mental powers that draws me deep into a project/task. Every project has a certain amount of mundane clerical work involving gathering and preparation of resources. Tools must be acquired, honed, and placed within arms reach. The tactical action plan, well supported by relevant skill and knowledge, must be devised in the context of an understandable strategic objective that supplies the entire endeavor with overarching metrics and meaning. Once all this infrastructure is in place, then that’s when I can surge forward with the greatest speed and surety I can muster. It is exhilarating, and this is when I feel most “me”. Or perhaps more accurately, it feels like the “me” that I wish I could be all the time.

I also get this feeling from certain games (Quake 3 Arena, back in the day), from running up and down the gears in my car, from brainstorming intensely with my peers, and from certain kinds of music. In most projects, though, the amount of time spent managing and gathering resources far exceeds the amount of time spent in the fast lane. I want my brain to run flat out at the greatest speed, always! FAST FAST FAST!

A Race Prep Approach

This gives me an idea: perhaps I can borrow the idea of having a “pit crew” and a “driver” from auto racing and apply it to my own projects. Clearly there’s the support aspect to every project that I find tedious, and I find it tedious because I want to be RACING. On the other hand, I can also appreciate the competence and knowledge required to provide high-quality support; it’s really important to me too. It’s not easy! My desire to make awesome, excellent projects can perhaps be better served by adopting the right hat at the right time, and by making sure that my “races” happen frequently enough that I don’t become overwhelmingly bored with support work. Before, I have mashed it all together under one hat, and this just makes me keenly aware that I’m “not racing” all the time.

So it might break down like this:

  • SUPPORT WORK: Knowledge acquisition, documentation, gathering, invention, process confirmation, time management metric, configuration in context with an upcoming “TEST RUN” and eventually the “RACE” itself.

  • RACING: When I get to run flat-out and burn up all the resources that the support work has gathered. It’s the big KABOOM. It’s the speed run! The challenge! The test! And hopefully, the big win in the form of a product release or launch.


p>I think it’s an interesting reframing because it’s the RACE STATE, when I get to go full-blast, that is the important context. Without setting that context explicitly, “support work” tends to fall victim to procrastination and distraction, and “the useful work” seems way too small to feel like meaningful progress. I love the idea of prepping for a speed run burst instead. This could have interesting ramifications for the design of a new task motivation system.

Let’s see how the race metaphor can be applied this week. I have plenty of boring projects to get out of the way!


  1. Daniel 10 years ago

    You need ZTD habits(Zen to Done), not GTD. It’s incredible. Search in google.

  2. Kevin 10 years ago

    The most useful nugget from Steven Pressfield’s books was the bit about starting before you’re ready. I wrote about it here: http://kevinrothermel.com/blog/start-before-youre-ready

    But after reading your post and thinking about it some, I think that I sometimes don’t start something because I don’t feel like putting in the hours that day. Not sure if that means that I know I’m going to get absorbed and then nothing else will get done, or if it’s just that I don’t have the available energy to immerse myself.

    Or it could just be the internet. That’s always a possibility.

    I’ve been working similarly to your race analogy for awhile, and it generally works. I use contexts in Omnifocus to separate out the admin and preparation for projects from the actual “work.” The only problem is that the work list is intimidating to see.

  3. The hardest part for me is the last 10-20%. It’s not just that the interesting problems in a project have been solved, it’s past the 80% mark that you have to start thinking about what constitutes “adequate enough for shipping” and doing a whole bunch of testing. It’s also the point where you realize that if you release it and it doesn’t make a splash you might have wasted a bunch of time. So then in an effort to avoid that, you find new problems to add that need doing before you can release something. Sigh at myself.

    On a sidenote, I kind of like the quirk nature of html/css/js/php, I have no resistance toward it, but I really, really hate browser testing.