Spring into Technical Writing

Simon P. Chappell writes "There is a school of thought that if you cannot explain what you've done, then what you did was worthless. Perhaps that attitude is a little extreme, but in this highly networked world of emails, instant messages, wikis, blogs and webpages, the art of explaining oneself well is important. While there are many books that teach written skills, there have been few ostensibly aimed at technical folks. Enter Spring into Technical Writing for Engineers and Scientists by Barry J. Rosenberg, a technical writer and the author of a number of technical articles and books including the KornShell Programming Tutorial." Read on for the rest of Chappell's review. 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.

Comments

Can someone please explain....

[Linuxthess]

What the hell was he just talking about?

Why isn't this book called ...

[Anonymous Coward]

... Technical Writing Hacks for Engineers and Scientists?

The Structure

[intmainvoid]

The book is split into four sections, each building upon the output generated in the previous section.

You mean, like 99% of every other non-reference book out there?

Nice review

[14erCleaner]

That was a surprisingly well-written, easy-to-read review.

Of course, maybe that shouldn't be surprising, given the book you just read. Sounds good.

Why shooud I take tecnical riting?

[pg110404]

My riting is just grate. I don't need there book to tell me how to rite better.

Now I goota get back to my tecnical documenteation for this project I'm dooing over hear.

BTW, wat excactly does a java inturfaice do again?

The art of technical report writing...

[VectorSC]

I was going to say something mean about technical report writing, but I can't really describe correctly exactly how I feel about this subject.

I'm not worried about my job!

[Tsu Dho Nimh]

I'm a professional technical writer ... and I'm not going to worry that engineers or programmers will learn how to write so well that I'm redundant.

However, if they could just learn to write a decent paragraph or two explaining the way their newest brain-child REALLY works, I'd be a very happy writer.

Types of verbs

[Alphabet Pal]

If you can name more than one type of verb

I can name lots of types of verbs! English verbs, Spanish verbs, Mexican verbs, Japanese verbs, ...

1337 Speak

[BinBoy]

I'm disappointed with the lack of a 1337 speak chapter. How can I explain myself to my colleagues on IRC?

"Techinical?"

[Anonymous Coward]

It looks like there's at least one word the class didn't help you with :)

Re:One problem

[AnonymousKev]

Funny. I've noticed that problem also exists in the area of software design.