Reading someone else’s novel can be tricky. What level of feedback is right? How much is too much? Should you focus on a few big things, or try to do everything? It’s hard, it’s slippery, and it’s easy to mess up. But do you know what makes beta reading really hard?
The fact that writing is subjective.
Yes, yes, we all know that. But when I say “writing is subjective,” you might think I’m saying that I’m saying: hey! Everyone likes different things! So feedback’s hard because what you hate might be what someone else loves! That’s what I meant, right?
No. That’s not what I’m talking about. Believe me–I very firmly believe that there are objective, craft-related challenges that I can identify in most novels. When I say that “beta reading is hard because writing is subjective,” I’m talking about an entirely different problem: the fact that almost every challenge you encounter can be fixed in an infinite number of ways. And that means that if you come up with your own solution to a problem, and you pitch that to the author, you might be doing them–and maybe you–a disservice.
This is probably easier to understand with an example.
So here’s a story of a beta reading gone wrong.
I was once a young, teenage novelist who had lots of teenage novelist friends. We were all terrible at writing because we were new to writing. We definitely knew nothing about critiquing.
Terrible, teenage-writer me wrote a novel about a mage and his familiar. They were good friends, but they were both moderately terrible people, and they loved to give each other a hard time. Every time one of them failed, the other would laugh about it. They were friends–they freaked out when their friend was in danger, and always helped each other out–but when the danger was past and all was well, they’d laugh at the other’s mistakes.
I gave this story to a writing friend and asked her to review it. She later pinged me (probably on AOL, because my awful teenage writing days were a very long time ago) with a passionate lecture: “I hate the familiar. She’s the worst character in the story. She’s awful, she’s mean, and she adds nothing to the story. Remove her.”
That was the whole of it. That was her biggest, most important, most crucial piece of feedback. Remove her! All of her. The whole character. Bam.
This was not a reasonable ask. The familiar was the second protagonist. She had POV scenes. She was important in nearly every major event. There was absolutely, positively no way to remove her without fundamentally rethinking the story. So I looked at this incredibly intimidating piece of feedback and, thankfully, had the presence of mind to ask her why. This is what I got:
- She didn’t read the characters’ interactions as “ribbing.” She thought they were mean to each other. She interpreted their teasing as fighting.
- She was sure that friends wouldn’t act this way, and she didn’t notice when the story told her otherwise. She genuinely read several tens of thousands of words and concluded that I was writing a story about two people who hated each other and cut each other down.
- She clearly didn’t enjoy this part of the story.
- So when I asked her for feedback, she decided to come up with a way that resolved all this ugly tension. And hey–if the familiar wasn’t in the story, this entire relationship wouldn’t exist. Problem solved!
So that was her feedback: I read your story and I hate that character. Remove her.
Why is it dangerous to dictate a solution to a problem in a story?
That said, I was a young, teenage writer. The beta was probably right that something was terribly wrong in that story. The characters probably did suck. They probably didn’t act enough like friends. They probably were too mean. And I definitely must have done an abysmal job of characterization if she read the entire thing and thought “Why do these two mutual enemies hang out with each other?”
So what was wrong with her feedback? Why wouldn’t you want to go up to an author and say “Hey, you know what? Take one of your characters.Unmake them. Destroy them so completely that no character remembers they ever existed.”
Because–and here is the lesson I have taken about a thousand words to get to–deleting the character was not the only way to fix that problem.
- I could have gone through all of the conversations where the characters rib each other and reworked what they said to each other. Maybe they were too harsh. Could I have made it sound more like teasing?
- I could have added context. How do the characters react when they’re being teased? If they’re genuinely hurting each other–ouch. Yeah. That isn’t great. But if I changed how they reacted, then maybe I could have made it clear that they weren’t hurting each other.
- I could have looked at the scenes where I “proved” how much they cared for each other–the moments where they rose to the call and did everything they could for their friend. Did those scenes exist? Were they making the point I wanted them to? I could have made those more powerful,.
- Or maybe the whole dynamic just wasn’t working. I could have changed their relationship, reworked the two characters, and removed that dynamic entirely, while still keeping them both in the story.
Or, yes, I could have yanked her out of the story.
But that’s the problem with solutions. Writing is subjective, and that means there are a million different ways to fix every problem you encounter. The pacing isn’t working? Maybe you need less detail. Maybe you need different detail. Maybe you need to add context. Or events. Or characters. Does your scene not make sense? Maybe you need to rewrite it. Or add something. Or change what leads into it. Or fix what comes out of it.
If you identify a problem in a story, awesome! The writer needs to know that. But if you rush right past the problem, identify the first solution that comes to mind, and tell the writer to do that, you’re not giving the writer the option to consider the myriad other ways they could fix the same issue in a different way.
So you’re saying I should never propose any solutions, ever?
No! Not at all.
For one thing, there absolutely are situations where solutions are appropriate. Grammar is often a matter of right or wrong. Obvious factual errors need to be fixed. Sometimes something is just wrong, and obviously wrong, and the only thing you can tell someone is “Hey, [this] should be [that]” and there’s a limited number of ways to fix something.
It’s also totally fine to give solutions as examples. For example, here’s how I structure my feedback:
- I point out something that caught my attention in a story.
- I explain why I feel it’s problematic.
- If it’d help illustrate what I’m thinking, I’ll give an example of something that would, in my mind, resolve the issue I’m having–and why.
I put the example in context. Maybe the reader will look at my explanation of what I found and why I think it’s an issue and go, “Ehhhh… No, this is fine. I don’t think everyone’ll read it like this.” Or maybe they’ll go “Shoot! You know what? It has been 7,000 words since anything happened. That’s a lot!” And maybe my example will inspire them. Or maybe it’ll help generate ideas. Or maybe they’ll hate it and decide to do something else.
But if I just drop down from the heavens with the One True Correct Answer, the author is much more likely to go “Why on earth do you want me to do this thing? I don’t like it, so I’m just going to assume you’re wrong and have strong, fiddly opinions that I don’t agree with. Writing is subjective, after all!”
So focus on what you found and why it bugs you and let the writer figure out the rest
On the other hand, if you arm a writer with something general, like “This section may be slow, and here’s why I think that’s the case,” the writer can look at it, decide if they agree, and come up with a solution that they love: something that came out of their head, fits their vision, and also resolves the issue.
So if you’re doing a beta, remember: tell them what you found and why it matters. But don’t tell them to delete one of their protagonists. Not only will the author remember that 20 years later (apparently), but it won’t help them as much as it could, anyway.