Technoscribe Limited

Home    Technical Writing    Illustrations    Other Services    Contact


Books we keep close by

We use Developing Quality Technical Information (Hargis and others) as our reference for topic-based writing and especially for creating instructional material. Published in 2004 it seems to cover everything we could hope for, stopping short of a style guide but giving plenty of stimulation to seek existing standards or set out new ones when we need them. Horowitz and Hill’s The Art of Electronics (1982) remains our favourite hardware textbook, with a readable approach that lets you understand its subject at your own pace. Even though it harks back to those days when a sneeze didn’t blow every component across the bench.

If we are struggling with a sentence or find that our grammar just seems odd - or if we really have to use apostrophes to show possession by plural nouns with a singular form, we return to Terence Denman’s How Not to Write. This was a good book for a long train trip, with enough anecdotes to make its messages stick. The Ladybird Book of Spelling and Grammar (Audrey Daly) brings comfort when we meet an engineer who knows their subject perfectly but struggles to explain it.

Stuff You Don’t Learn in Engineering School (Carl Selinger) touches ‘writing’ but more usefully addresses the life skills we need to extract the information in the first place, and works well with Robert Rohm’s Positive Personality Profiles.

Microsoft Access appeared in 1992 and to us it represented a watershed in the conundrum between database design and usability. The Access 2 Developer’s Handbook (Getz, Litwin and Reddick) stays within reach, with much of its advice on normalization and query design still good. Indeed it proved its worth for a task in Access 97 and 2000 without leading us astray.

Just about everything that claims to be a system nowadays seems to use something or other from the TCP/IP protocol suite and W Richard Steven’s TCP/IP Illustrated Volume 1 remains our reference here. Stevens wrote two more volumes, but if we needed them we would probably be writing the software or devising a new protocol.

Most publications need graphics, flow charts or photographs, and we keep a handful of books (mostly now long out of print) to cover essentials for illustrations. For the words themselves, an old-fashioned dictionary (a book instead of an on-line one) helps to keep spellings consistent throughout the life of a project. We use an Oxford Concise one, not for any special reason except this one usually gives prominence to international spellings. Chambers English Dictionary is a fallback when the ‘Concise’ does not ring true ... now was that online or on line?

Back to Technical Writing