I know what you’re doing. You’re sitting there staring at your laptop screen. Your’re probably making this face:
And you’re getting nowhere. If this is you, keep reading. There are three things you can do right now to fix your manuscript problems.
Step 1: Quantify the Problem
Those of you who have followed me for a while know that in addition to being a writer, I’m also a software engineer. Software engineers—the good ones at least—are big on process. Software engineering, on the other hand, is big on bugs. It’s inevitable. We put a bunch of smart people in a room together and have them develop elaborate computer program designs. What could go wrong?
For starters, those “smart people” all have the same trait in common. They’re human. Humans make mistakes. More so, it seems, when a computer is involved.
There’s a truism in software development: we cannot fix a bug unless we can reproduce it. It’s just that simple. Anything else is a guess. An educated guess, perhaps, but a guess nonetheless.
In other words, we must first know what is wrong. I’m not talking about the effect. I’m talking about the root cause. What you may not realize is that this also holds true for writing. You can’t fix it if you don’t know what’s wrong.
You may not be able to determine this yourself. If you’re beating your head against the monitor and you just can’t figure it out, don’t be afraid to share it with a trusted reader. An objective person may be able to shed some light on it for you. But know this: until you know specifically what is wrong, you won’t be able to fix it. So ask for help if you need it. The sooner the better.
Step 2: Develop a Plan of Attack
Now that you have some idea of what is wrong, you can start wrapping your head around what you may need to do to fix it.
I’ll dip back into the software engineering example for a bit (no pun intended…oh who am I kidding!)
Every line of program code we write has an associated cost. Cost to maintain in labor, cost in memory, cost in processing power, cost in…the list goes on. So we can’t just roll up our sleeves and start writing code. That’s a surefire way to cause another problem.
So what do we do? First, we have to know what all the “touch points” are, as we call them. Every piece of code we write potentially effects one or more other pieces of code. It’s very easy to create a cascading domino effect of problems with a single line.
This is true in your manuscript as well. So before you go writing more prose, have a plan of attack for how you’re going to address the secondary problems that will arise. What’s a “secondary” problem? I can think of a few examples right now:
- Fixing the main problem requires getting a character off stage.
- Secondary problem: That character was going to reveal a critical piece of information. Uh oh.
- If you move the gun to the top of the mantle now, you don’t have the main problem later.
- Secondary problem: The maid cleans the mantle two scenes ago. She would have found the gun!
- If your magic system was capable of creating a wall of water, it will set up the solution to the problem in act 3.
- Secondary problem: Your wizard wasn’t able to help a minor character put the fire out that burned down the guard house that led to act 2!
I think you see what I mean. It’s not rocket science, but it will cause you headaches if you march in blindly.
Step 3: Work the Plan
This may be the hardest part of all.
Back to software engineering for a moment. I like to think software engineers are all around decent people. Many of us got into programming because we had an arcane set of skills that could help solve other people’s problems. So, being the problem solvers that we are, we’re always looking for problems to solve. We’re always thinking “If I just add this feature, the user’s life will be so much easier,” or, “if I move this widget from here to there, the application will look nicer.”
So while we’re fixing the main problem (which we already developed a plan of attack for in Step 2), we’re also adding new features or changing existing ones. And guess what…
We’re causing the problems of tomorrow that won’t be found until next week. Certainly not on purpose! But everything we do is a human endeavor. That makes it prone to mistakes by its very nature.
There’s a term we use to describe certain types of program code: “Fragile”. When we use this term it’s often derogatory, but in essence it means it’s prone to break when you change it or seemingly unrelated code.
Prose is fragile. It’s fragile because when we write it, we’re adding transitions, solving plot holes, managing continuity, and manipulating character arcs. It gets to a point where it doesn’t lend itself to change without a lot of back-breaking work.
When you develop your plan of attack in Step 2 and sit down to actually implement it, you have to be careful that your writer/editor mind is not intruding and suggesting other changes that will “make the story so much better”. If it is, do your best to ignore it for now. Take some notes if you’re afraid of losing the ideas. But remember: your prose is fragile. If you add extra beats, change a character arc, or drop in a new plot twist, you may be breaking something else without realizing it.
Trust yourself and your process. You identified a problem. You developed a plan to remedy the problem. Now work the plan.
This is the 3-step process I followed to fix every problem I identified in early drafts of Necromancer Awakening (now an Amazon bestselling fantasy novel). This technique has served me well, and I believe it will serve you too.
Sign up for the free Erindor Press newsletter. Stay Informed. Be a better writer. Your contact information will NEVER be shared for ANY reason.
Join Nat on Facebook for additional content that he doesn’t post on the blog or on Twitter.
Be part of the conversation! Head on over to The Mukhtaar Estate and see what everyone’s talking about!
Nat Russo is the Amazon #1 Bestselling Fantasy author of Necromancer Awakening and Necromancer Falling.
Nat was born in New York, raised in Arizona, and has lived just about everywhere in-between. He’s gone from pizza maker, to radio DJ, to Catholic seminarian (in a Benedictine monastery, of all places), to police officer, to software engineer. His career has taken him from central Texas to central Germany, where he worked as a defense contractor for Northrop Grumman. He's spent most of his adult life developing software, playing video games, running a Cub Scout den, gaining/losing weight, and listening to every kind of music under the sun.
Along the way he managed to earn a degree in Philosophy and a black belt in Tang Soo Do.
He currently makes his home in central Texas with his wife, teenager, mischievous beagle, and goofy boxador.