It is a sad experience to receive a book of your work in print… and then to start seeing the mistakes. All of which you had combed for a billion times, but still slipped through.
It is a sad experience to receive a book of your work in print… and then to start seeing the mistakes. All of which you had combed for a billion times, but still slipped through.
M | T | W | T | F | S | S |
---|---|---|---|---|---|---|
« Aug | ||||||
1 | 2 | 3 | ||||
4 | 5 | 6 | 7 | 8 | 9 | 10 |
11 | 12 | 13 | 14 | 15 | 16 | 17 |
18 | 19 | 20 | 21 | 22 | 23 | 24 |
25 | 26 | 27 | 28 | 29 | 30 |
2014 Appearance Schedule
ABQ Comic Con Emerald City Comic Con TCAF (with TopatoCo) More to be added... past conventions |
Powered by WordPress with ComicPress |Subscribe: RSS
My first wife and I did medical transcription for 10 years, and we quickly learned to proofread each OTHER’S work, not our own. Since then I have learned to read everything I’m proofreading twice, but no more than twice. By then all the mistakes you missed the first two times have become canon.
Maybe there are gremlins who sneak in while the book’s being printed, adding mistakes back in?
I find it helpful to read it backwards to check because then things jump out that normally wouldn’t.
I write computer software for a living, and it’s pretty much accepted (among those of us not too egotistical to admit being fallable) that the best way to find your mistakes is to have somebody else review your code. I work in a small shop where I’m the only firmware developer, so I’m pretty much on my own. There are great freedoms that come with running the effort by yourself, but there’s no lifeline, so it can also be scary.
One difference is that, frequently, the mistakes made in software show up when you try to run it; whereas mistakes in writing for humans only show up when somebody notices. Contrariwise, the source of the former can be difficult to track down from the effect; whereas the latter are right there in your face, as you’re reading the source.
I’m going to stop myself right there because I tend to over-analyze everything and I eventually I’m going to have to eat lest I starve. Which, at my current bulk, could take a while.
Anyway, there are techniques for structuring code development, some of which include peer review and/or programming in groups, that are intended to mitigate the problem. (Nobody seriously expects any of those to eradicate bugs. Merely to minimize them.)
The first issue of our magazine had 48 pages and 69 errors. We had seven proofreading cycles, some by the editors, some by the art staff, some by the publisher’s wife, and the ones we had to pay for by the printer. When I moved production to computers, with spellcheck and in-house layout, we had ONE outside proofreader who came in just before layout, and our error rate dropped more than 90%. Your errors can become invisible to you, and going over and over the text again and again simply wearies you and doesn’t improve the text. One of the reasons you hire proofreaders, better yet an actual editor, to read your MS before sending it out.
No one is immune. One of the senior VPs at the company I used to work for later had the privilege of writing a letter to the tens of thousands of employees in Canada. Only when his own copy came to him in the mail did he spot the glaring typo in the first paragraph. Great guy. Very literate. Was blinded by the importance of the task. Like anybody else could be.