Writing Can Be Refactored Too

In “The Boundaries of Agentic Coding”, Tison mentions a habit for handling duplicate code: the first time you write a piece of logic, just write it straight through; the second time you run into something similar, copy and paste it first; only on the third time do you consider whether to extract shared code.

The point of doing this is to figure out one thing first: are the two pieces of code actually expressing the same idea, or do they just happen to look alike? That is often hard to tell when you first start writing. If you rush to merge them simply because they look similar, then as soon as requirements change later on, you have to stuff the function with parameters and conditionals just to split the two paths apart again.

I think writing has the same problem. An outline settled on too early is like shared code extracted too soon.

When an idea first occurs to me, I do not necessarily know yet what I want to say. A thought can seem complete in my head, and only when I start writing it down do I realize a step is missing in the middle, or that there is a sentence I cannot explain clearly no matter how I try. To fill in that missing step, I have to find another example, or separate two cases I had originally lumped together. As I keep writing, even my initial judgment may change along the way.

Changes like these are hard to build into an outline in advance. If I lock down the structure in too much detail at the start, writing turns into forcing content under each heading; when a more interesting thought comes up halfway through, I also have to hesitate over whether it counts as going off topic. Yet for a piece that is still feeling its way forward, that “off-topic” detour may well be the part most worth following. Insisting on sticking to the original outline at that point is just like cramming parameters into a function to accommodate an existing abstraction: the more you revise the piece, the more awkward it gets.

So I prefer to start by just writing things down as they come: a sentence, an example, or a small disagreement with a particular claim.

Only once I have a few concrete paragraphs in hand do I have something I can put side by side and compare. Looking back then, I can tell which two paragraphs are actually saying the same thing and which two only look alike on the surface; I can also see which example really holds up the argument, and which lines are things I simply wanted to say that the reader does not actually need.

When I refactor the piece after seeing all this clearly, what changes is not just the wording, but also the order. The order in which I worked something out for myself is not necessarily the order that works best for a reader. A reader needs a certain premise first to understand the judgment that follows; some parts belong to the same question and should be brought together, while others need to be split apart. Sometimes a sentence that originally sat at the very end works better moved to the opening.

Reorganizing text with AI is very convenient now, and I can ask it at any time for several different orderings to compare. Before doing that, though, I still want to first put down the rough sentences that genuinely reflect what I am thinking. With those original words as a foundation, when I read a revised draft later, I can tell which edits are helping me make my meaning clearer and which ones are merely making the text sound more like a standard essay.

Of course, if you are writing an explanatory piece whose conclusion is already clear, making an outline first will save a lot of trouble. I am talking about a different situation: when you are still feeling your way through, with only a vague sense that there is something there. At times like that, you might as well write for a while first, wait until you have some concrete material on the page, and then look back to decide how the piece should be told.