This post is inspired by Tessa Flattum’s post, “How to Write a Novel with ADHD.” I self-diagnosed my own ADHD after my son was diagnosed as a child. I’ve written three technical nonfiction books on cybersecurity. I agree with her general observations, but my own experience is a bit different.
First, she points out that ADHD manifests itself differently in different people. Definitely true. We can’t even tell which weird behaviors are part of this alleged “disorder” and which are separate and annoying parts of our underlying selves.
Second, I agree that attention isn’t the problem, it’s allocation of attention. Flattum calls it cycling. Others call it the Shiny Object problem. We work on something, the interest wanes, and then attention is grabbed by something else. She talks about this as motivation by dopamine: we don’t get enough dopamine as we get close to finishing things, so other things grab our attention.
If I’m motivated to do something (like write this post) then I focus on it to exclusion of all other things. Or at least I focus on it until my available time or focus burns out. These days I leaves half-finished blog posts in my wake. Now that I’m officially retired I’m not trying to do anything more sophisticated than blog posts. I usually finish them before I lose interest, even if I’m interrupted. But not always.
Flattum makes five observations and recommendations for how to complete your work while coping with ADHD:
- Learn your biorhythms. If you’re not a morning person, don’t try to make yourself into one, or vice versa. I agree. ✔︎
- Try pantsing your novel. She seems to mean: once you have your general idea, start working by the seat of your pants (I guess). Don’t waste too much time making plans you won’t follow. I disagree, and will discuss. ✘
- Get a body double. In other words, do your work around people doing similar work. For example, try writing in a coffee shop or library with other people working. I agree because that’s how I finished my dissertation, but it’s become less important as I’ve gotten older. ✔︎
- Use a reward system. This is to get a shot of dopamine when we make “good” progress without necessarily finishing something. Set a near-term goal (like finish this blog post) that may be less than the ideal (writing a book, or a distinct piece of it) but at least represents progress. Reward yourself when you reach that goal. I disagree because I personally lack the discipline to withhold the reward. ✘
- Have lots of snacks and drinks on deck. I disagree because hunger rarely makes me stop when I’m really focused on a task (like right now). But I agree with the concept: have the essential resources at hand so you aren’t interrupted while working. I achieved this by getting larger and then multiple video displays, and working near my bookshelves. ✔︎
Planning Versus Execution
I’ve wrestled with the related engineering problem for most of my life: we want to separate the design process from implementation, but can lose the benefits of the design while implementing. When I worked in software engineering, the design process helped us clarify our thoughts and assumptions. The process most often failed if one person did the design and another did the implementation, unless we could enforce consistency somehow. For example, we might generate template code from the design itself to use in the implementation, or we might test the software against the documented design. These don’t really apply to designing and building manuscripts.
I generally make outlines and use them to construct my written materials. Typical outlining software provides headings and subheadings, and I can attach zero or more paragraphs of text to each. In graduate school I used ThinkTank and MORE for writing papers and finishing my dissertation. MORE died out when Apple moved from their original Macintosh software base to Unix-based OS X. After that I used outlining built into MS Word and whatever other writing apps were on my Macintosh.
The outline provides my design for the document: chapters, sections, subsections, etc. The attached text paragraphs provide the implementation. Outlines are hierarchical and my technical nonfiction is usually hierarchical. Outlining software allowed me to rearrange sections and subsections as I fleshed out a document. The outline would then evolve as I added text to the document. When sections got too large I could rearrange the structure to accommodate the extra text.
The outline also gives you little bursts of completion. You can fill a sub-subsection with the text it needs, and you’ve finished a chunk of the project. If you’re inspired to write a lot of material, you keep writing. The outline reminds you of where you’ve been and where you are headed with the discussion.
Having said all that, let me talk about how I’ve gone about writing this particular article. I started with a fairly clear and specific vision: use Flattum’s comments as a starting point to discuss my own experience. The only thing I really wanted to discuss was my use of outlining. I did not break that discussion into details or the order in which I’d cover them.
Since I wrote without further planning, even in my own mind, the article digressed about a software engineering problem dear to my heart before getting to how I use outlines. One might say that the only on-topic paragraph in the previous section is the final one.
The bottom line: you must find a process that works for you.