Think Before Doing
I’m going to tell you about a powerful idea that keeps showing up for me. This idea has helped me enormously in my life. In a nutshell, we often get stuck not knowing what to do because we don’t realize that we need to prioritize thinking something through. That thinking can also be greatly facilitated by using pen and paper or computer and keyboard.
Positive Mental Attitude
In my early twenties, I read a book called “Success Through a Positive Mental Attitude.” This book was given to me by an ex who I later realized projected pretty much all of her negative self-evaluations onto me. That included her negative thinking and her unwillingness to learn new things. I took this book and read it again and again, partly because it resonated with me and partly because I love learning. That same ex later told me that I read a lot of books but never learn from them. I often ask myself, “Is that true?”
One of the key ideas in “Success Through a Positive Mental Attitude” is the use of pen and paper as a tool to aid in thinking. As I remember it, the book doesn’t fully explicate this idea, but it has stood out in my memory, and I’ve returned to it many times throughout the decades. Only recently, finally, have I come to understand what the book was referring to, and it’s what this article intends to explain.
“Albert Einstein developed intricate and profound theories regarding the universe and the natural laws that control it. Yet he used only the simplest—but most important—of instruments ever invented: a pencil and a piece of paper. He wrote down his questions and answers. You will develop your mental powers when you learn and develop the habit of asking yourself questions—when you learn and develop the habit of using pencil and paper to write down your questions, ideas, and answers.”—Napoleon Hill & W. Clement Stone in “Success Through a Positive Mental Attitude”
Get Things Done
Thinking before doing is the principle that underlies David Allen’s “Getting Things Done,” the process that involves getting to “inbox zero.” The idea is that you whiz through your inbox and do thinking up front to decide what you need to do about all of it. The trick is to not get stuck for more than a minute or two dealing with any one item. Later, once the high-level thinking has been completed for all the emails, they have been filed, and projects and tasks have been created or updated, then prioritization and execution can commence.
Getting Things Done is about thinking about projects and tasks and capturing and organizing that thinking into a document, on paper or in a computer. This produces a plan that you can effectively execute.
“Use your mind to think about things, rather than think of them. You want to be adding value as you think about projects and people, not simply reminding yourself they exist.”—David Allen in “Getting Things Done: The Art of Stress-Free Productivity”
Cindy (my wife) and I went on a vacation to Europe this past summer. We had decided that we wanted to visit Paris, explore central London, visit my mom who lives in the outskirts of London, and also attend a retreat in Devon, which is on the south coast of England. We found ourselves confused and unable to plan properly. We didn’t know how long to stay in each place or how to get between the places. It was stressful for us, and the stress escalated into some small arguments.
This is when I decided that we needed a Google spreadsheet. I created a table with each column representing a day. To this, we could add dates that we had decided were not movable, or at least very sticky, such as a music concert we wanted to attend near home, a conference I wanted to drop into, and the dates of the retreat in Devon. These were the stakes in the ground that put reasonable constraints on our plan. Cindy sat on our sofa, and I sat at our desk and we both looked at the same document at the same time. We discussed it as we worked on it. Take a look at the table below.
The months, August and September, are at the top, along with the days of the month and the days of the week. Below that are three rows, the first row showing where we would physically be, the second row counting off the whole days we would spend in each location, and the third row counting days of vacation from work. Blue is used to represent days spent traveling. Orange represents weekends and holidays. Green highlights the days of the retreat. The black triangles in the top-right corners of some of the cells in the “Stay” row open up into notes when the cursor hovers over the associated cell. These notes contain plans for each day.
It’s easy to judge this as over-the-top and unnecessarily nerdy, but it worked incredibly well. As soon as we started playing with this, we had fun. Now we had a living document that we could view and edit, that we could reason about, that we could make concrete decisions about.
After laying down an initial plan, we made several major revisions to minimize travel time and the need for a rental car and to make sure that we had enough time in each place to do all the things we wanted to. After less than an hour, we had a plan so thoroughly nailed down that we could book flights, accommodation, and transport. We regularly referred to this plan before and during our vacation.
This plan is a great example of up-front thinking, using a living document that facilitates clarity and communication.
“Writing is thinking on paper, or talking to someone on paper. If you can think clearly, or if you can talk to someone about the things you know and care about, you can write—with confidence and enjoyment.”—William Zinsser in “On Writing Well”
My son and I are working on a computer program that simulates the behavior of a colony of ants. The group behavior of efficiently finding resources and returning them to the colony’s home will be an emergent property of the combined behaviors of the individual ant agents.
Like all young software engineers, my son wants to jump right into coding. He has not yet seen enough complex projects through from start to finish to understand that slowing down and developing a high-level architectural approach leads to much higher quality outcomes. This behavior of jumping straight into writing lines of code is familiar to those who conduct technical interviews. When the candidate takes time to think the problem through, draw some diagrams, and scope out a solution, the resulting lines of code come easily and tend to function correctly. On the other hand, when the architectural decisions are made as the bricks are laid, messy confusion ensues.
I don’t want my son to get lost in the weeds of spaghetti coding and never experience the satisfaction of developing a bug-free, highly-performant, yet complex program, so I’ve been charting the course ahead of him, scaffolding the architecture, and leaving pseudo-code clues. Again, this process looks very much like the thinking-before-doing approach that I’ve already described. Below is some pseudo-code I wrote for him outlining how an ant agent might decide about direction changes.
There’s nothing wrong with diving into code without a plan. This is actually a great way to learn. However, once we’ve done enough of that, we become confident that we can write code that does something. From that point on, the challenge becomes figuring out the higher-level aspects of a solution so that the details can be implemented more correctly and completely first time, with the low-level decisions more likely to serve a higher-level plan.
“The sooner you start to code, the longer the program will take.”—Roy Carlson
Back in the early days of my engineering career, I used to write code that described how digital circuits on silicon chips would function. This code, called RTL (register transfer language) would then be used to simulate the chip’s behavior and confirm that it was correct. That same code was also used to synthesize the physical chip, using a library of pre-designed primitive transistor-based logic components.
The RTL code, written in a language called Verilog, would be stored in plain-text files, written with simple ASCII (American Standard Code for Information Interchange) characters. I found that it helped me to construct documentation and plans before writing any code. I wanted to keep the documentation with the code, so I created this documentation as blocks of non-executable comments at the top of each file. I even drew diagrams using ASCII characters.
After taking a break from my engineering career to get a Ph.D. in clinical psychology, I returned a couple of years ago. On returning, one of the things I rediscovered, or more deeply discovered, is the power of design documents. I’m not talking about meaningless, template-driven busy work mandated by corporate processes that attempt to harness quality through control. I’m talking about noticing that what I should do next is not clear and recognizing that it’s an opportunity to slow down and create a living document, a thinking tool, a tool that enables me to clarify what I already know and understand and also to uncover what I don’t yet know and understand. These documents, growing organically out of the problem, are structured efficiently and naturally to convey the plan and facilitate its refinement through interactions with the author and other readers.
I am discovering that when I wade into unfamiliar territory and the complexity of the work causes me to fall out of flow, slowing down to document brings me back into productive flow. So then creating the document is fun. Then, once the design or architecture document is complete, and all the ambiguity and confusion has been flushed out, the work of implementing the plan can be done while in flow, full of enjoyment.
Whatever is actually happening has the key to effortless enjoyment. When what you’re working on seems challenging, confusing, overwhelming, or boring, it’s a sign that you need to slow down and clarify what you need to figure out. That process itself is usually a lot of fun and leads directly into an enjoyable flow state that can be continued long after the plan has been created. And all of this results in a massive increase in quality. Quality can’t be forced; it’s the result of work done while in flow. The quality that is produced is then inspiring to you and all who encounter it because it reminds everyone of a state of contentment and fully engaged flow.
This article has been republished in The Coach.