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.
30.4393696-97.6200043
Like this:
Like Loading...
Related
Comments 17
If I keep making that face, think it’ll freeze that way? Cuz if so, I might have a serious problem.
I’ve resigned myself to perpetually looking like a cartoon character. 🙂
Love the llama face. Sooo used to feeling that way….
I’ve definitely grown accustomed to the feeling over the years 🙂
Nice! A fellow computer nerd appreciates your analogies 🙂
Fresh eyes reading your work are so, so important for picking up things you never even realized were a problem. Fortunately, it’s way easier for me to get my spouse to sanity-check my manuscript than it is to convince my business users at work to perform user acceptance testing! 😉
I hear ya! The first thing to slip, traditionally, is always the testing schedule. I’m fortunate to work in a place now that understands the importance of good testing procedures (we develop medical devices…so people die if there are bugs). But everywhere else I’ve worked, that hasn’t been the case. In fact, I’ve worked for development shops that were convinced hiring testers was a poor use of resources and that programmers should do their own testing. Nasty stuff!
Yep, that’s where I’m at! We have no dedicated QA groups or roles in my organization. Programmers test their own code, then a business analyst will run through a test case they made themselves (and they might not know anything about making good test plans or even be experts on the system in question). After that, it goes to the users for UAT- and good luck getting them to do it, even if you give them a test plan and detailed instructions for everything!
Good times! 🙂
I think I’ll apply your techniques and blend them in to others that I have found for the dreaded editing process. Thanks Nat.
That’s a great idea! Combine and blend until you come up with something uniquely your own.
Great article! Thanks for posting. Completely agree with your methods on tackling the draft manuscript – though, would call them ‘easy steps’ 🙂 Nothing easy about a preparing a manuscript for publication in my experience!
Once again, thanks for posting 🙂
Author
I’m glad you liked it, Helen! It’s true, “easy” is very much a relative term here 🙂
You also sound like you have a bit of project management experience, this all sounds veeeerrrrry familiar! (I’m a PM/BA).
Author
Not directly, but my day job is in project-based work (software development), so I’ve worked with my fair share of project managers. Ironically, I attempted technical project management earlier in my career and failed horribly! In that specific case, however, I had 5 bosses (no kidding), so I was always guaranteed to have 4 angry people thinking I was the worst project manager on the planet.
I’m a technical project manager and BA, specifically investment trading software, so I’ve got all sorts of hassle hitting me from every direction! I plan all of my novels anyway but find if I’m full tilt on a large project my outlines become very strict and ordered, black and white. Sometimes good, not always so.
Pingback: Michille: Passive versus Active | Eight Ladies Writing
Before starting working at my current WIP (a trilogy of novels) I had only worked on short stories. So I had to learn writing novels on the move.
First thing I learned, if I can write a short story aon the fly, I can’t do that with a novel. I need to plan.
Second thing, I need at least two passes before I feel I have a plot. So in those two passes, everything is fluid. Nothing is settled, because what happens in ch 2 may end up happening in ch 6. Writing a novel turly tought me to keep an open mind. It’s very confusing when you move everything around, so many things keep changing. That’s why you need to plan.
Third thing (and I’m learning this now), you come to a stage you can’t trust your own judgment anymore. This is very weird. When I write shorts, I know I need more or less three passes and the story is fine. I can see where things aren’t quite right and see right away how to fix them. Not so with novels. I may feel something is not properly working, but i need someone else to look at the story and tell me how they feel about it. Then, I can see the problem and even see how to fix it. But at this stage (I’m on draft 7 at the moment) I cannot see the problem by myself anymore.
So I’d say what I’ve learned about revising is: keep an open mind and don’t do it by yourself 😉
Author
Fantastic advice! I definitely second what you say about getting to a point where you can no longer see the problems. You’ll always get to a point where you have to share your work with an objective third party to make further progress.
I’m very similar. I tend to free write short fiction, but I always need an outline for novel-length work.