Debugging a manuscript

Source codeMy novel Amiga will be published by Black Rose Writing on November 27, 2019. I will describe my publishing journey in a series of posts. This is the first of this series.

My computer industry experience provides more than the subject and inspiration for my novel Amiga. It influences how I tackle one of the more challenging and important parts of writing, editing.

A benefit of working with a publisher is getting expert feedback from editors. The notes I got from the acquisition editor provided valuable information about where my story needed improvement. But how do you turn feedback into a stronger manuscript? Here’s where my computer industry experience helps.

At my technical writing job, I work with two types of feedback. The first are bugs. If something is incorrect or out-of-date in the documentation, it’s my responsibility to fix it. Usually, the engineer or QA tester who writes the bug is clear about what has to be changed. Other times, I need to do research and ask for clarification. Fixing bugs is an iterative process. When I make a fix, QA tests it again. If I fixed it correctly, the tester closes the bug. If more changes are needed, the tester reopens the bug, I make the fixes, and it gets tested again.

The second are error messages. I’m in charge of maintaining the code that generates help and PDFs from our documentation source files. If something doesn’t work right, the software generates error messages like this one:

Warning at char 3 in xsl:param/@select on line 71 column 46 of dita2html5Impl.xsl: SXWN9000: The parent axis starting at a document node will never select anything.

Not much better than the Guru Meditation errors on the Amiga, huh?

Fixing errors like this requires a lot more research, work, testing, rework, and retesting. I also have to make sure that fixing one bug doesn’t break something else. Debugging is like solving a puzzle. You follow the clues, put together the pieces, see what is feasible, and create a solution. The goal is to produce a better product.

You can look at feedback on your manuscripts the same way.

When you’re told a scene doesn’t work or a character seems flat, you can look at them as bugs. They are not criticisms of you or your story. They are things to fix to make your story better. Use the information as clues for solving a puzzle. Put the pieces together and see how you can use them to do a better job connecting with your readers.

Great feedback is golden. Use it to fix the bugs in your story.

One comment

Comments are closed.