Making the Future

I have the habit postponing decisions until I know enough. Sometimes this is good; I can avoid the thrash of haste by letting the information landscape settle. Other times, it is paralyzing. When operating in some novel or obscure environment, there is no way to get enough information to be confident in what next steps to take – in essence, there is no map for me to follow. My struggle is to avoid the latter, which can become an impediment if not managed.

But, what does “enough” mean?

In cases you must make a decision, information is a confidence-building material that exists right now. It already happened, and can be evaluated. For example, you might consider past failures (due to some understood fault) or successes (due to your cunning and skill, no doubt). Imagine frequently using such information – heaps of anecdotes, case studies, and personal experiences. It is a lot to think about. Now, consider how faulty we all are when it comes to recall. Do we remember the good as easily as the bad? The successful as well as the failed? Do we remember our faults as well as those of others?

By focusing too narrowly on such information, we can fall in to a trap where we try to produce a future state by following the remembered past instead of learning from it. This is especially true involving novel or obscure problems. We have no information for these problems yet. We just have the experiences that guide our thinking.

As an alternative, what if we consider focusing on the future via destinations or goals? What state or conditions do we want to have in place? What outcome do we want to achieve? What system do we want to work better, and how? Who do we want to be at the end of the journey? These questions ignore how we got to the present state and make the decision about a desired future state. So long as the destination remains unchanged, the decisions to get there remain stable. The downside is that, if the destination or goal isn’t fixed, those decisions can be in conflict as you go. Thrash ensues.

Focusing solely on information (where we used to be) puts our thinking in the past. Focusing solely on destinations and goals (where we want to be) puts our thinking in the future. Both have consequences if done in extremes:

• When choosing tools for a new software project, you could focus on popularity or age of the tools, what the team already knows, etc. (information) OR what suits your learning goals or the problem being solved (destination/goal).
• When deciding what to cook, you could consider the current state of your larder or what you know how to make (information), or what you have a taste for or want to learn to cook (destination/goal).
• When planning your day, you could focus on what commitments you’ve put off already (information), or what you plan to complete in the coming days/weeks/months (destination/goal).

Given that comparison, and the fact that neither focus area is the perfect antidote to planning success, what should we do? As I mentioned above, I know my bias is to prefer information when making decisions. What types of problems do I encounter that benefit from this focus? and, which do not? In thinking about this, am I committing the same mistake‽

Instead of a specific answer, I have come up with a list of questions to guide myself to think more in the future when problem solving and prioritizing. These are specific to software projects, but could be adapted to other domains:

• Are solutions to the problem undefined?
• Does the problem block anyone (me, the team, the company)?
• Is the problem functional (involves important behaviors in the code)?
• Is the problem aesthetic (consistency / structure / design)?
• What do I (or the team, or the company) gain by solving this problem now?

I recently tried this out on a little personal project I have been working on. When I first started working on this several years ago, I fell into the trap of relying too much on the information I already had. All of the questions were like holes in my map to completion. So I lost steam and let it stagnate. How could I make project with all these gaps in my information?

I hadn’t considered that my project WAS the holes in the map.

I changed my approach. Instead of worrying about all the things I did not yet know, I doubled down on defining what I wanted to accomplish.

• There were solutions to the problem. In this case, I wanted to experiment and learn VueJS.
• I was essentially blocking myself by waiting to learn how to use everything … without trying to use it at all?
• I knew how I wanted it to function. I was replacing an old page I built years before.
• Most of my problems here were aesthetic (I did not have a design to reference; it was all in my head).
• The whole point was to learn new tools and technology. The thing I hoped to gain was staring right back at me.

In order to learn, I had to do something. So, I first did my redesign in isolation. Now I had a target look and field to build for. Next, I defined all the important functionality as tickets to work on. I mapped out what I wanted to accomplish both in terms of look/feel, and function. Having all of this together made it much easier to consider and compartmentalize my next steps. I felt like making progress again because I separated the things I already knew from the things I wanted to know.

I can now focus on learning. Put another way, I can focus on what I hope to know some day soon.

There is still more to do, but I now look forward to continuing this work in the coming weeks and finally replacing this old, creaking monstrosity that I made years and years ago.