Spring into Technical Writing 173
| Spring into Technical Writing for Engineers and Scientists | |
| author | Barry J. Rosenberg |
| pages | 318 (with an 18 page index) |
| publisher | Addison Wesley |
| rating | 9 out of 10 |
| reviewer | Simon P. Chappell |
| ISBN | 0131498630 |
| summary | Solid writing advice for technical folks. |
Who's it for?
The book's full title pretty much nails the intended audience; it is absolutely for engineers and scientists. Unlike most works on literary skills, this book treats you like a geek and realizes that you don't want to write prose, but you do want to communicate through a written medium. If you read Slashdot on a regular basis, know what Linux is or the majority of your books have diagrams, figures and tables instead of pictures, then you are a candidate for this book. If you can name more than one type of verb, then you may well be better sticking with your copy of The Elements of Style.
The "Spring into ..." series of books is based around the idea of transferring concepts quickly and efficiently. Barry, editor of the series as well as the author of this book, recounts his experience of a few years ago, when he had to learn a number of new skills quickly and could not find books that would meet that need. In his own words, "I didn't have time to become an instant expert, but I did have to become instantly competent."
The Structure
The book is split into four sections, each building upon the output generated in the previous section. The first section introduces the reader to the concept of technical writing, including how it varies from the other sorts, and then covers how to plan your documentation. Section two covers the actual writing. It starts with words, moves to sentences and progresses to paragraphs, before bringing in lists, tables and graphics. Section three looks at specific types of documents that are meaningful to engineers and scientists including manuals, web sites, proposals, lab reports, PowerPoint presentations and emails. The fourth section teaches basic editing skills, core concepts of typography and a discussion of practical punctuation.
Chunky, and I don't mean soup.
The series explains its topics in one or two page units that it calls chunks. The individual chunks in a chapter build on previous chunks. Delightfully, there are plenty of good examples throughout the book and each chunk has at least one example in it.
What's to like?
I found much to like about this book, and if any of these points ring true with you, then there's a good chance that you'll like it too. The first thing to note is hopefully obvious, and that is the quality of the writing. Or at least I'd hope that it would be obvious that the writing was excellent in a book about writing! There is an upbeat and cheerful tone that, even with a few corny jokes in the footnotes, doesn't cross the line into being either saccharine or condescending.
After the quality of the writing, the thoughtful division into chunks pretty much make the book for me. The information within the chunks is excellent, well indexed and easy to locate through the table of contents. The chunks cover task-sized activities; for example, you might wonder if a semicolon would work at a certain juncture. So you turn to chapter 20, the chapter on punctuation, and then to page 286, where a straightforward explanation of the correct usage of semicolons (with five good examples) awaits you.
While there are many depths to be explored in writing, this book stays close to the surface, giving enough help and guidance without turning the reader into an expert on composition. All advice is targeted for the concept, in the context of the likely circumstances that an engineer or scientist would need it.
The book stays on target all the way through. The stated audience of the book is engineers and scientists, and that remains the focus throughout. This makes a delightful change from books that claim to cover advanced topics, but start out trying to teach you the basics; Java books seem to be especially guilty of this.
The third section of the book covers many of the types of written material that a reader may be called upon to produce and not only gives examples, but it also shares tips and lessons learned from experience for each of the document types. Examples include pacing a PowerPoint presentation and writing a book proposal.
Oddly enough, for a book written about writing, for a technical audience, by a professional technical writer who also teaches occasionally at MIT, there is nothing to complain about in the writing department. So, switching to scraping the bottom of the barrel mode: I didn't like the ragged-right text justification and a few of the jokes were very corny. That's it.
Conclusion
This book does what it sets out to do, that is to equip engineers and scientists with the skills to communicate clearly and effectively through a written medium; whether that be a website, an email or a report. I recommend this book to everyone, from organizers to doers. Organizers like to write about what should be happening, and doers, while they may tend to shy away from writing, are often asked to write about what they've done for the organizers. This book covers that full circle.
You can purchase Spring into Technical Writing for Engineers and Scientists from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Re:Techinical Writing in Progress (Score:1, Informative)
Read the Elements of style (Score:4, Informative)
Ragged-right (Score:2, Informative)
Re:How does this compare to... (Score:3, Informative)
I used this book when I went to college, and found it very useful when writing a variety of papers, from cover letters to resumes to technical reports. It quickly became one of the first books I reached for when writing any technical documents, such as a final report describing an AI program that I wrote in my senior year. I highly recommend it.
I was exposed to this book primarily because I was a CS student at an engineering college, and it often makes me wonder what my CS studies/reports would have turned out without this resource book by my side.
Re:Like a breath of fresh air (Score:3, Informative)
I hate to break it to you... (Score:4, Informative)
but if your code work does not either cut expenses or add revenue to your employer/client by at least the cost of your labor, expect to be out of a job soon*. That's all "value added" really means.
Also, comments matter as much if not more than the code. I'm not talking about stupid crap like:
I've seen stuff like that, and it's worthless. But real comments stating what problem you're trying to solve, and how you're solving it. Without that, what's to say the code is right or wrong? It's so easy to duff up a complex condition with misplaced punctuation or an AND in place of an OR. Explaining this condition in the code will help yourself and others understand what you mean when the code isn't quite saying it. Meatspace is still the Real World(tm), no matter how much we might wish it were otherwise.
* - an obvious exception is basic research work where it's pretty hard to quantify the value of what's done. Another exception is stuff one writes for the pure joy of it.
Couple of links (Score:2, Informative)
Technical writing tips: http://www.docsymmetry.com/index.html [docsymmetry.com]
Plain English Campaign: http://www.plainenglish.co.uk/index.html [plainenglish.co.uk]
Get it write: http://www.getitwriteonline.com/archive/tips.htm [getitwriteonline.com]
Re:What's the Point? (Score:2, Informative)
For me to hear you say that engineers don't need to communicate clearly is, frankly, scary. There are some great (yes, academic) articles out there tracing just how badly things can go wrong when engineers don't communicate well. One such article is pithily titled "Communication: The missing link in the Challenger disaster." Another is called "Understanding failures in organizational discourse: The accident at Three Mile Island and the Shuttle Challenger disaster." You get the idea. Good communication is everyone's responsibility, no matter how much my engineering students wish it weren't.