I am, by trade and training, a software engineer, and I have this tendency to attack my writing from the mindset of an engineer. Things have been happening this year (a sale! then another one! and a long phone call!) which have made look back on the journey, where I was and where I am and how I got there. The novel-edits have made me think about editing, and myself, and how I’ve dealt with edits in the past. And it brought to mind a term we hear a lot in this industry: Feature Creep.
For those of you not in software or unfamiliar with the term, I offer Wikipedia:
Feature creep is the ongoing expansion or addition of new features in a product, such as in computer software. Extra features go beyond the basic function of the product and so can result in over-complication, or “featuritis”, rather than simple design.
Or, put simply:
I’m currently undergoing some massive novel edits. It’s basically a rewrite. The things required to be fixed are subtle and have to be woven throughout the thing, and I’m faster at writing than I am at editing. I perpetually strive for efficiency.
We all know there are many types of crit. There’s the Oh Hey Good Point, and the Eh I Don’t Really Agree With That, and the OMG YES THAT, and the What Book Were You Reading Because It Certainly Was Not My Book. This post is mainly about dealing with crit. Not emotionally — because if anybody’s going to guide you on how to emotionally react to something, it should absolutely not be me — but practically.
I look at editing like I look at testing: It’s the part where I take the idea and make it work. Coding is like a rough draft. The more pre-planning you do, the smoother that draft will be, but no code is immune to the need for testing, and no draft is immune to the need of editing. (And if you disagree, either on the code or the writing side, well, I hate to tell you, you’re wrong. Sorry!)
And you can’t just test your code yourself. Other people should test it too. There’s nothing quite like a user who has never interacted with your software finally getting the chance to throw input at it which you didn’t anticipate and certainly didn’t code for. The same is with betas. They’ll read what you wrote, with their own set of preconceptions and experiences, and they will break your manuscript.
Sometimes the advice is really good. You hear it, and you say, “Oh sheesh, yes, that is a problem.” Sometimes it is not so good. It makes you cringe and ask, “Seriously, buddy, what is wrong with you?”
But sometimes, you see a crit, and you just don’t know.
Maybe you’re too close to it. Maybe you’ve had your confidence shaken. Maybe you’re a noob and the words are coming from a pro. Whatever the case, you just absorb suggestions and start putting them on the page because, Dear God, something has to work. And then suddenly, where you had an almost-working novel, you have a huge mess, and you start to wonder at your misspent youth.
There has to be a cutoff point. A point where you say, “No, I am not adding in All Of The Things, because simply put, I need to have this thing be done. I know you like dogs, dogs are pretty cool, but this is a book set in space and I don’t think a dog is really necessary.” Sometimes books try to do too much, and in trying, they do nothing at all. We’ve all read that book, I’m sure. This is a book that got plagued by feature creep.
I avoid this by one simple, hard-and-fast rule: If I don’t really agree with the change, I don’t do it. I don’t have to disagree with the change. Just being “meh” on it is enough. I may be willing to try a suggestion. After all, if I hate it, I can delete it. But if I’m not feeling it, out it goes.
All parts of the creative process require passion, and the edits I make are no different.