It took me a while to figure out how to write regularly. I had to do a lot of iterated troubleshooting before I figured out how to reliably generate output. It's possible that none of those are the insight you need, or that internalizing them is mostly not about having the words for the thing - but I figured it was low-cost to share anyway. Plus I want to write this up and now seems as good a time as any to put it in writing.

Iterated troubleshooting

Getting stuck was a regular thing, and cued troubleshooting rather than trying to push through.

I started doing this for "work in general" before I was doing a lot of writing per se, and it's probably the thing that helped the most. I wrote up some of my early insights on causes of procrastination here.

Keeping a messy workshop

I used to think that writing was the sort of thing where I should minimize the number of things in my queue:

My friend Satvik recently told me about an important project management intuition he’d acquired: it’s a very bad sign to have a lot of projects that are “90% complete”. This is bad for a few reasons, including:

• Inventory: For any process that makes things, it’s a substantial savings to have a smaller inventory. A manufacturer buys raw inputs, does work on them, and ships them to a customer. Every moment between the purchase of inputs and the delivery of finished goods is a cost to the manufacturer, because of the time value of money. Smaller inventories are what it looks like to have a faster turnaround. If a lot of your projects are 90% complete, that means you’re spending a lot of time having invested a lot of work into them, but realizing none of the value of the finished product.
• Power law: Some projects might be much more important than others. If you’re allocating time and effort evenly among many projects, you may be wasting a lot of it.
• Quality of time estimates: Things may be sitting at “90%” because they keep seeming “almost done” even as you put a lot of additional work into them. If you’re using faulty estimates of time to completion, this may make your cost-benefit calculations wrong.
• Mental overhead: Even if it were somehow optimal for an ideal worker to handle a lot of projects simultaneously, in practice humans can’t perform very well like that. Conscious attention isn’t the only constraint - there are also only so many things you can productively fit on the “back burner”.

I decided to use this insight to prioritize my work. Things that are “90% done” should be frontloaded, and idea generation should be deprioritized until I’ve “closed out” more things and cleared up mental space.

At first, this seemed good. I went back to a bunch of old blog posts that were "mostly done" and finished them. But then, with my queue newly emptied, I realized that I'd learned the wrong lesson. The important thing wasn't clearing out the queue, it was that the projects all got easier while I was away from them.

It can be good to have a bunch of projects going at once, so that when I'm tired of one I could switch for a bit. Often on a piece of writing, I'd get stuck after outlining it, or partway through, and then get distracted by life, and then come back and find that I'd had the crucial insight that let me make progress - or just could see what needed to be done, now that I was looking at it with new eyes. Once I noticed this, it was easy to do things on purpose.

Distinguishing explaining from thinking

Getting stuck is sometimes a cue that I'm not ready to write a thing down because I don't know what I think about the thing, so I need to go off and think instead of trying to put down my final words. Often this means I take a walk, or talk to someone about the thing.

More generally, I've benefited from foregrounding the distinction between writing-as-thinking and writing-as-explaining. Sometimes I know what the structure of the thing is pretty well, and there's a mental mode for just recording that. This involves lowered inhibitions, writing as if I were telling someone. Often I actually explain the thing to someone via text chat, and copy-paste the explanation into a document editor as a first draft. (This post was written that way.)

But other times, I need to write in order to organize my thoughts, so I shouldn't try to "structure" the whole piece in advance - at first I'm actually just taking notes to aid my own thought process.

Another thing is, sometimes if I'm stuck, it's because I'm trying to explain something in too few words, and I need to start another document to explain it. This can lead to a lot of backwards-chaining, and ends up resulting in blog post sequences, but these are basically a fine outcome once you accept the messy workshop paradigm.

Say the bare minimum

Sometimes I need to outline stuff by writing an extremely bare-bones description of the thing, then fill in the bare minimum to make it intelligible and grammatical. This can help if I'm stuck on saying it "well" and often results in better style. Sometimes, the bare-bones outline just is what I wanted to say.