I’ve been feeling stalled in my code project. The code project is super-important to me because I want it to become the home base for my project planning and strategic goal assessment. But first, I have to get unstuck.

When I get stuck, it’s sometimes because my choices of action have payoffs that take more time to develop than I have patience for. Without immediate payoff, motivation wanes and my will to act is lessened. Even worse: the shape of the award in the case of design is not obvious or easy to imagine, which creates uncertainty and doubt. The desire, however, still remains strong. It’s not an action goal, but the childlike desire to just want something GOOD RIGHT NOW. So my mind toggles between childish cravings, uncertainty, and impatience. I want the satisfaction of immediate action, but I lack the certainty of what that action should be, because the payoff is both in the future and of unknown quality.

If I am procrastinating, I will satisfice by finding something to do that is at least certain (like having a snack), provides a more immediate reward (surfing the net for other solutions, perhaps), or is something that I already know is useful (doing some chores, doing something related to the business). But the BIG HAIRY TASK doesn’t go away. The only way is through. That means addressing each of those pain points. So let’s do that right now.

• First: the problem of immediate payoff. I know it took me 21 days to get to the point where I could just save data from a web page. Because I blogged my way through each step, I felt I was capturing useful information that I could use later. I also produced a blog post and record of my activities, so that was sufficient to provide intermediate feedback as I learned to crawl. The problem now: I’m not particularly looking forward to doing it again for the front-end design, but it’s something I just have to accept.

• Second: the problem of unknown characteristics for success. The payoff should be, uh, a useful interface for keeping track of my tasks in the context of my big-picture goals. I know it should look good and also work well, but I’m not sure what it will look like. To resolve this problem, I have to force myself to go through a design cycle. What makes this difficult is that I don’t know what the optimal solution will be. This is a common blockage point; the solution is to just pick ANY solution that I can implement, and test it through implementation.

• Third: the problem of uncertainty of the time needed to reach a quality result. I don’t know what the solution is, but I can dispel uncertainty and replace it with experience. To do this, it’s necessary to design a program of exploration, giving myself permission to take the time to discover the design principles that will make this work. This is unknowable before you start. But my experience also tells me that it usually takes less time than you think, once you commit to making that first mark on a piece of paper and seeing where it leads you.

<

p>For a non-mission critical project like this, the process of making progress should look something like this:

1. State what the application should do.
2. Pick a solution. This is not necessarily the best solution; it’s merely one solution.
3. Evaluate the solution as it’s implemented. Collect the useful lessons learned into a journal post.
4. Go back to 1, with an increasingly-refined sense of what is important.

So let me apply that to my web app.

1. It should keep track of tasks in a way that is easy to enter, reorder, and edit.
2. I can see it implemented as a bunch of DIVs in a containing DIV. So let’s try that now, and see how badly it goes.
3. Keep notes and evaluate the outcome.
4. Iterate.

I think it’s useful to address my uncertainties also, because these are the criteria by which I’ll be evaluating the work. Right now, I’m uncertain about the following:

• TIME: but I’m accepting that it may take a lot of time.
• VISUAL DESIGN: I want this to be sweet and slick, but I don’t know what that looks like yet. I am thinking of starting with a bare text layout, no graphics, to get the information hierarchy correct first.

Again, I find that small motions to just get the brain moving helps get me unstuck enough to build a bit of momentum. The trick is to gather ENOUGH momentum to bust through LARGE creative barriers. There’s a big difference between “fold my laundry” and “create a cool task app”. The former is a known quantity of time and effort, even if I don’t want to do it. The latter is far more filled with uncertainty. It’s also quite different from when I’m getting paid to do that and am directly responsible; the interaction with other people gives me the boost.

So when approaching those large tasks, somewhat overwhelmed by the number of variables that are swimming in my head, the first act to bring it under control is to linearize my thoughts into groups. If I liked Mind Mapping I would do that, but I find Mind Mapping visually unsatisfying. There are two ways I start the linearization process:

• I write a stream of consciousness entry, like this, talking my way through the process until it seems like I know where I am and what I am doing.
• I scribble in my notebook or on a small whiteboard, drawing pictures and making notes to myself.

I haven’t found a way to combine these two activities effectively, now that I think about it. I’ll have to work on that. Products like Evernote theoretically would help, but I don’t like the interface.

…

Ok, I think what I need to do, to get moving on that code project, is to start scribbling in my journal first and pull out a small list of things to do. This never takes more than five minutes, I should remember. Then, move to development-journal style work and push through a big chunk of effort. To make it seem doable, I will again start with a 15-minute minimum, for at most 2 hours.