Tuesday, August 25, 2009

Peer Reviews

I have a like/hate relationship with critiques. I can’t say love/hate. I’m not sure I’ll ever love a critique. I might love the final product, though.

The whole concept of critiques is basically the same as the peer review process that software engineers use. At work, when I write code, it gets looked at by 1-4 other people on the same team. Not by managers--we are not students turning in our papers for a grade by the teacher. But by peers. In peer reviews at work, I get a variety of types of comments, depending on the specific people reviewing the code.

Some people get very caught up in what we call "coding standards". These are things like how we name variables, where blocks of comments go (comments are human-readable notes that explain the program code, but don't actually affect what the program does). In writing, this would be the spelling and grammar. I've noticed that the people who are excellent at checking this kind of detail frequently get so caught up in a typo in a comment that they couldn't tell you whether the program will actually work or not.

Do we need them in our peer reviews? Absolutely. The same goes for our writing. If there are so many spelling and grammar mistakes that they get in the way of the story, then the writing is not the best it can be.

At work, there are some reviewers who wouldn't know, much less care, whether your strings variable names start with str or sz or abcdef. They follow the code. They can read what is happening, and tell, without even running the app, whether the code will work or will throw up big ugly error messages and bring down your entire computer. For writing, these people are like beta readers. They can digest an entire story and tell you that the hero is too much of a jerk, or that your villain is too flat. They know when the romance has your toes curling, or your stomach curdling. But they might not have noticed that you have twice as many commas as any sane writer, and that you spell "heroine" "heroin" nine times out of ten.

Do we need them in our peer reviews? Absolutely. The same goes for our writing. We need someone who can see the big picture and tell us whether our puzzle pieces will fit together into a cohesive whole.

And then there are the "I Know Better" folks. You know the ones--they don't like something because they would have written it differently. In code, they would write a "for" loop instead of a "while" loop, and will insist to their dying day that the "for" is best, regardless of whether the "while" loop worked correctly and efficiently and ended up with the same result. They just think that their way is better.

In writing, these are the contest judges who re-write half of your manuscript in the margins. They insist on "rules" being followed that don't work for your manuscript. They don't like your setting (even though its integral to the plot), think your alpha-hero should be beta, and want to see more sex in your inspirational.

Do we need them in our peer reviews? Well, this one gets tricky. At work, these people are frequently the team leader, or the chief architect for a project. In this case, their word is the final word. If they say, and insist, that you use for loops instead of while loops, then sometimes you say "Yes, sir" and just do it, no matter how aggravating. In my opinion, a good team lead or architect will either 1) recognize the value of an alternate solution or 2) Explain very clearly and non-condescendingly where the weaknesses are in your work and why they feel that their own idea is better. But I've met many who do neither of these things.

Do we need them in our writing? Heck, no. Most of the time. When you are writing, you are the team lead. You are the chief architect. It is your name that will show up on the cover, so you call the shots. There is a caveat here: If you are getting this kind of advice from someone who is published in the sub-genre that you are working in, then don't discard their advice out of hand. Keep it. File it away. And come back to it later, when the pain and annoyance isn't quite so fresh. There might be some nuggets of truth or help hidden in there. If not, keep on ignoring.

At work, as in writing, we need a mix of people to help us critique our work. And it might change depending on where the writing is. If you've written a fast draft, or just an outline, then you're going to want to listen closely to those big-picture folks. If your story is nearly carved in stone, then you want that close-read by the grammar guru to really polish things up. And most critique partners will fall somewhere between the two extremes.

I am lucky right now that I have a good small critique group with a mix of folks. We're at different stages in our writing--from contracted to working on the first draft of the first book. We write in different genres--historical, contemporary, light and dark paranormal, suspense. We write at different speeds. But we all have something different to bring to the table.

So, even though I cringe every time I send out a few pages, and hold my breath waiting for the critiques to come in, I know I'm getting valuable feedback.

1 comment:

Robin Bielman said...

It's tough letting others read your work, isn't it? But as an aspiring author, I think it's essential to get that feedback too. Sometimes it's not what we want to hear, but in the long run, we'll be better writers for it.

Enjoy your critique group and happy writing!