Customer Reviews

Bugs in Writing

5 star:		(7)
4 star:		(6)
3 star:		(4)
2 star:		(2)
1 star:		(1)

 

 

This is an annoying book. The author of this book claims that she wrote it for "computer people" whom she goes on to define as just about anyone who has visited the computer aisle in a bookstore. I was briefly employed as a technical writer while in graduate school and have found writing a constant part of technical employment in industry. I am currently a computer science professor who firmly believes that students need to learn how to write. Consequently, I incorporate writing into many of my courses. However, I can not recommend BUGS in Writing by Lyn Dupre.

Although the author cites the Manual of Style published by the University of Chicago Press, she failed to take to heart a number of its recommendations. In particular, her use of footnotes is excessive and often distracting. The overall design of the book appears very self-indulgent with its copious use of personal photographs unrelated to the text. The author is committed to "gender free" text to the point of altering the accepted names for famous computer science problems such as the Traveling Salesman Problem to suit her personal agenda and insists that others do likewise. She allows other petty issues to spoil her work. For example, she writes: "A dissertation is a document that you write as part of the fulfillment of requirements for a degree¡Ä A thesis is an assertion that you have presumably validated or proved ¡Ä" This is contrary to accepted practice at many and probably most academic institutions. While Martin Luther may have nailed his 95 thesis to a church door, some schools call even the paper presented for a doctorate a "thesis" while others reserve the term for a work presented for a master¡Ēs degree. Current practice is to begin scholarly works with an "abstract" and not a "thesis".

Another of Dupres personal crusades is expressed in a foray against "split infinitives". She writes as if split infinitives are a recent abberation. In The Elements of Style, Strunk and White note that: "There is precedent from the fourteenth century down for interposing an adverb between to and the infinitive it governs." They also note that the "split infinitive" has a role when the author wishes to stress the adverb as in "To boldly go where no man has gone before." Strunk and White go on to note: "Some infinitives seem to improve on being split." Dupres¡Ē partisanship in the slit infinitive "wars" is much less disturbing than her one-sided account of the split infinitive.

Her diatribe against use of "data" as a singular in computer science is also excessive. Data is the plural of datum in Latin. The problem with treating data as a plural taking "are" in computer science is the distinction in English between enumerable and non-enumerable nouns. While there are uses of the word data where it is clearly plural, this is not the case in much of computer science literature where it is used in a non-enumerable sense. In English, the tradition is to treat non-enumerable nouns as singular. An odd recent development is pluralization of "email" as "emails" while "mail" continues to be treated as non- enumerable. Finally, data is often used as an adjective in computer science. English traditionally uses singular nouns for this purpose such as "horse barn" or "cow pasture" in preference to "horses barn" or "cattle pasture". Similarly, a famous English university is commonly called Oxford and not Oxenford. Insisting upon treating data as a plural would have much more serious consequences than portrayed by Dupres and other opponents of data as a non-enumerable. Under her system, we would properly write of "datum structures" rather than "data structures". In short, English majors should not meddle with semantics of individual words until they learn the field of discourse employing those words.

Although the author claims to have written a book for "computer people" she seems to be unaware of typesetting using LaTeX or the electronic style sheets provided by technical publishers. She also appears ignorant of coupling typesetting equations with output produced by either Maple or Mathematica. Although her book does contain a brief section on theorems and similar material, this section is too short and lacks sufficient detail to aid the reader. Despite her attention to typography, she does not make a clear recommendation on how to emphasize technical words in a work with lots of italicized text.

Some of the author's advice is well taken. She justly condemns use of passive voice in scientific writing. Her insistence on maintaining noun constancy is also well worth reading. Problems with noun consistency is exacerbated if you anticipate translation into Japanese where variation in nouns is less tolerated than it is in English. Unfortunately, even some of her good advice betrays a lack of understanding of computer science. While Dupre correctly argues for using monospace fonts for typesetting code, she appears ignorant of the reasons for preferring this convention. In one piece of advice she uses writing about stacks and queues as an example, but in her example labeled "good" she delivers confused prose which betrays ignorance of the subject. This spoils an otherwise good section.

In a world with many excellent books about writing, I can not recommend buying Dupre's book. If you are specifically interested in writing for computer science, then you should buy and read a copy of Writing for Computer Science by Justin Zobel. If you wish to write mathematics, you should buy and read a copy of How to Write Mathematics by Steenrod. The Art of Readable Writing by Rudolf Flesch continues to deliver excellent advice on writing in a much more compact package than Bugs in Writing. I also recommend Manual of Style by the University of Chicago Press, The Elements of Style by Strunk and White, and A Handlist of Rhetorical Terms by Lanham. As for BUGS in Writing, I can only speculate that Ms. Dupre made the error of editing her own book.

As a technical writer, I am on the lookout for books I can recommend to engineers and others with whom I work who want to improve their writing. This book's explicit orientation toward "computer people" and the concept of "debugging" prose make it seem like a good candidate. However, the author's self-indulgence in cuteness in this book renders it inappropriate for me to recommend in a professional context.

If you don't mind all the cat pictures and personal references, it is a good book to browse for tips on improving your writing. Dupre states that her goal is to help the reader develop an "ear" for good writing. As you develop an ear, you will gain a sense of which of her rules to take to heart, and which to take with a grain of salt. It is *not* organized or indexed such that you can easily find a topic again. Do not expect to use it as a reference book when you have finished browsing.

This book is wonderful; this book rots. One thing for sure -- it's different!

HITS:

1) Informal, nonstuffy feel.

2) Covers a lot of material.

3) Has lots of examples.

4) Does a good job of showing the dynamic and subjective nature of English writing.

5) It is one of the very few style and grammar books that I've read that lends itself to being read like a book of short stories: sit on the john and make yourself a better writer. Now, THAT'S innovative.

MISSES:

1) MUCH physically bigger than it needs to be; thus, it is hard to use as a quick reference. The typeface is too big, but most importantly it is full of completely useless tangential photos. There are between 100 and 200 photos that, while cute, have no place it this book. Some reviewers seem to like this. I find it unprofessional. Would you enjoy paying extra money for a book to look at a stranger's family album? Think of the natural resources wasted on this silliness. If the author wants to write a picture book of her cats, that's fine, but she should market it to people whom get some benefit from it; I submit those people are an extreme minority in the readership of this book.

2) Does not use direct counter examples. So, instead of seeing an example bad sentence corrected, you see a different sentence done right. The author defends this as helping to develop "ear." I usually find it more annoying than helpful.

3) Does not cite sources of her opinions, and therefore it is very hard to take anything this book says as the final word. To be fair, she does warn that it is often just her opinion and not rock-solid fact. Differentiating them is the problem. This shortcomming results in you having to look items up in another book to make sure before you commit something to paper. Need an example? She states that ending a sentence with a preposition is drop-dead wrong. It is not; it is very debatable. I found several more scholarly books that state that is simply not true anymore, if it ever was. One book made an excellent case that this belief is a prejudice stemming from Latin grammar.

4) It's hard to find items in the book. The "Index of Principles" is okay but should probably be called something else and placed in the front of the book. There is no regular index.

5) The cover is butt ugly.

6) The book cover suggests that the book should be filed under General Computing. Now that's insulting. What's this about; do you have to trick technical types into writing better? "Gosh, I was looking for a Java book, and I stumbled on this Bugs book. Now I write much better."

Should you buy this book? I have no idea. Do you like cats?

As a professional author with over 49 books to my credit, I've collected a number of guides to writing over the years. This book sits on my reference shelf right between Strunk and White, and the Chicago Manual of Style. I recommend it to other authors on a regular basis because it contains so many clear examples that are easy to read and understand. As far as I'm concerned, my reference shelf would be incomplete without this book.

There are two reasons that I like this book. First, it isn't dry and hard to understand. I like a little humor when I read. Second, the examples are clear and easy to follow. It's easy to write a book that defines writing in terms that only an English major would love. Writing a book like this is difficult, and I appreciate the author's hard work.

If this book had exercises for the reader, I'd have used it as a textbook for introductory technical writing classes. It's organized into big, rich chapters with lots of examples -- which is just the ticket for folks who are learning new skills.

For an experienced writer seeking advance on points of usage, I think there are more concise style guides -- but none funny enough to read for pure pleasure.

One caution: Dupre's prose style, while ornate, is clear and eminently readable, but writing like Dupre takes a great deal of skill and practice. A lot of the examples of "splendid" writing are compound-complex sentences with lots of flourish and flair. Such sentences may be dangerous models for total novices to follow.

This book describes what to do and not to do when writing in English, and it is so funny and entertaining that you pick it up and read one advice after the other. The book is divided into short articles each covering one topic, making it a good companion when riding the train to work or for travels.

Books giving advice on better writing are often extremely dull, meaning that they are left unread - therefore, if you want to start with just one book on better English usage, 'Bugs in writing' is the best choice.

Lyn Dupre has worked as an editor of technical and scientific litterature, and the book focus on the use of English when writing instructions for users of software and scientific articles

Bugs in Writing is a "Strunk and White" for the technical crowd. In short, easy to digest (though occassionaly conflicting) sections, Dupre covers the writing problems she has encountered while editing technical manuscripts, and lays out clear examples of how to fix them. I keep this book within easy reach.

I just recently finished a technical book and the book and Lyn's advice to be spot on. She flags the problems that I had with my writing style (or lack thereof).

Her style of writing is quirky, but entertaining. I enjoyed it immensely.

If I had bothered to read the book before I started righting my own book, I would have finished my book in much less time.

A cautionary note: this book is for TECHNICAL WRITERS. A book for the scientist who is writing, or the computer programmer who is writing. This book won't work for your novel about summers in Rome.

I already had ordered this book from Amazon, but I just cancelled it.

While I was checking my order I found style examples in the excerpt of the book which I strongly dislike and disagree.

One of the book's examples I saw is the following:

---------------
UGLY: In a stack, both insertions and deletions are performed at one end only; both poping and pushing are allowed.

GOOD: When you use a FIFO list queue, you make insertions, at one end of the list, and deletions at the other end; you therefore must maintain rear and front pointers.
---------------

First of all, after giving the UGLY statement, the author must show how to write a GOOD statement which expresses the same idea as the UGLY one. But, she does not. Instead, she writes a statement which expresses a different idea. So, how one knows the correct way of writting the original idea? Clearly, the example is useless.

Next, the statement she labels with GOOD has many unnecessary words, and, for my taste, is UGLY. I, instead, would write something like this:

"A queue is a list where insertions are made at one end, and deletions at the other end; therefore, to manage a queue, a front and a rear pointers are needed."

My statement is easier to understand than the author's supposedly GOOD statement, and does not have its unnecessary words.

I suspect that the author does not have science education nor is a writing style expert. Because if she were familiar with scientific writing, she would know that satetements should have the minimum number of words, and she would not insist in introducing the unnecessary and UGLY "when you use...", "you make...", "you insert..." etc. She must know that when a formal science or technical book or paper is talking about a concept X (like stacks, queues, memory, cpu, etc.), it has to talk about propiertes of X; IT DOES NOT MATTER WHO USES X.

The author, dogmaticaly and mecanically, tries to avoid every use of passive voice, getting wordy and ugly statements. She does not have elegant and imaginative means to convert from passive to active voice; she limits herself to use pronoun "you" as her "universal converter" ("When YOU use a FIFO list queue, YOU make insertions, at one end of the list, and deletions at the other end; YOU .... ").

Of course, most ideas are better expressed using active voice, but there are also many cases in which passive voice is more adecuate. (Please, do you find UGGLY this passive voice statement: "Most ideas are better expressed using active voice."?)

I use English as second language, mostly for reading. Nevertheless, I have checked many books and papers about writing style, and I always have found their examples instructive and better than what I would write. This is the first time I feel that the recommendations are worse than what I would write by myself.

There are at Amazon many other books about technical writing that have all the good things this book might have, but without those ugly examples thay might worsen your current style.

I particularly enjoyed the many examples Ms. Dupre provided with her topics. She did a good job making rules of grammar hit home. She also prompted you to actually THINK about the subject matter, rather than read the standard counterexamples found in most other grammar texts. For a student in a computer-related program with minimal english courses, this book does a great job in teaching good grammar with little pain.

However, the way the book is organized does make it hard to quickly find grammar rules. It's better used as a learning tool than a reference.