When Things Work Before They’re Elegant

There’s a phase in any sufficiently complex project where things have to work before they can be good.

In software, it’s the point where the code runs—barely—but it’s held together with duct tape and optimism. You know it’s fragile. You know it’s inefficient. But it functions, and that helps you see what needs fixing.

Writing has the same phase.

I hit it hard with Draft 2.0 of Book Two.

The First Half Held. The Second Half Didn’t.

Draft 2 started well enough. The structure felt solid. The pacing worked. The character arcs were lining up the way they were supposed to.

And then, about halfway through, it just… ran out of steam.

Not in a catastrophic way. The scenes were there. The plot beats existed. But something was off, and I couldn’t put my finger on what.

I knew where the story needed to go. I had the destination clearly mapped. But the path to get there felt sluggish, inevitable in the wrong way, like the story was trudging through obligation rather than building momentum.

The instinct was to stop and fix it immediately.

Great. But I didn’t know what to fix yet.

You Can’t Debug What You Can’t See

In code, you don’t refactor before the program runs. You get a proof-of-concept, get it functional first—even if it’s ugly—because until it executes, you’re just guessing at what’s broken.

Writing works the same way.

I pushed through the back half of Draft 2, even though it felt off. Not because I was in denial, but because I needed to finish it before I could see the problem clearly.

Once it was done—once the full draft existed as a complete, if flawed, system—I could step back and actually diagnose what wasn’t working.

The Inventory Pass

With the draft complete, I did what I’d do with any broken system: I took inventory.

I went through the back half scene by scene and asked:

• Does this need to stay?
• Is this in the right place?
• Is this doing the work I think it’s doing, or is it just occupying space?

Some scenes were fine. They stayed.

Others were clearly in the wrong order—creating drag because the tension was arriving too late or resolving too early.

And a handful were dead weight. Not bad scenes, necessarily, but scenes that existed because I thought they should be there, not because the story actually needed them.

Once I saw that clearly, the fix became obvious.

Subtraction, Then Reordering, Then Forward

I cut three or four scenes outright. Not salvaged, not reworked—just gone.

Then I reordered what was left, moving a few key moments earlier to create the pressure the back half had been missing.

With that structure in place, I could finally see what the last half of the book actually needed to be. Not what I thought it should be when I started Draft 2, but what it had to be now that the rest of the story had clarified.

And then I was back on track.

Functional Before Elegant

Draft 2.x always feels worse than Draft 1.x.

Draft 1 is exploratory. You’re discovering the story, so rough edges don’t bother you—they’re expected. Everything is provisional.

Draft 2 is where structure starts to matter. You’re not exploring anymore; you’re building. And the first version of that structure is almost never elegant.

It’s functional. Barely. And that’s uncomfortable.

It feels like you should be further along. Like the draft should be better by now. Like you’re regressing instead of progressing.

But that’s the wrong way to think about it.

Draft 2 isn’t about elegance. It’s about getting the structure to hold long enough that you can see what’s actually load-bearing and what isn’t.

Refinement comes after understanding. And understanding comes after the thing exists—even if it exists badly.

The Parallel to Code

There’s a reason experienced developers don’t try to write perfect code on the first pass.

You write something that works. You run it. You see where it breaks, where it’s inefficient, where the logic doesn’t hold up under edge cases. Then you refactor.

The same principle applies here.

Draft 2 had to run before I could see where it was inefficient. It had to exist as a complete system before I could identify the bottlenecks and the dead code.

Trying to make it elegant before it was functional would’ve been a waste of time—because I didn’t yet know what I was optimizing for.

Why This Phase Feels Bad (But Isn’t)

The middle of Draft 2—the point where it’s functional but not refined—feels like failure.

You’re not in the exciting discovery phase anymore. You’re not in the satisfying polish phase yet. You’re in the uncomfortable in-between where the thing works, but badly, and you have to live with that for a while.

It’s tempting to skip this phase. To try to make Draft 2 elegant immediately, to avoid the discomfort of a working-but-ugly structure.

But that’s a mistake.

The ugly-but-functional version is the only way you learn what the structure actually needs to be. It’s the diagnostic tool. It’s the prototype that teaches you what the final version should look like.

Skipping it doesn’t save time. It just means you’re guessing instead of testing.

Where Draft 2 Is Now

The back half is rebuilt. The pacing works. The scenes that stayed are doing their jobs, and the ones that left aren’t missed.

Draft 2 still isn’t elegant—but it’s solid. The structure holds. And now I can refine without second-guessing whether the foundation is stable.

That’s progress.

Not the flashy kind. Not the kind that feels like a breakthrough.

But the kind that means the next pass won’t be a structural rewrite—it’ll be actual refinement.

The Takeaway

I’ve learned that when a draft feels worse than the last one, it’s usually not a sign I’m moving backward.

It means I’m in the functional-but-not-elegant phase—and that’s exactly where I need to be.

Trying to polish before the structure holds doesn’t work. I have to let it exist, even when it’s ugly, so I can see what actually needs to stay.

Elegance comes after understanding.

And understanding comes after I’ve built something solid enough to stress-test.

Enjoyed this? Get the science behind the story → Join the list