TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
>I'd also suggest you get _Code Complete_, by Steve McConnell
I second that. Here's my August 1993 (how time flies!) review of it
from IEEE Micro.
Code Complete by Steve McConnell (Microsoft Press, Redmond, 1993,
If you are or aspire to be a professional programmer, this may be
the wisest $35 investment you'll ever make. Don't stop to read the
rest of this review. Just run out and buy the book.
Many computer books are as thick as this one, but few have as much
reason to be. McConnell's stated purpose is to narrow the gap
between the knowledge of industry gurus and common commercial
practice. To do this he sets out to explain everything important
that those gurus know about programming The amazing thing is that he
This book addresses a huge gap in the education of programmers.
Whether they are high-school amateurs turned pro or computer science
graduates, most programmers know only scattered bits of the large
body of practical knowledge about programming.
I don't know of any formal apprenticeship programs. The few
programmers lucky enough to be apprenticed informally to masters
learn the techniques in this book. The rest are left to reinvent the
wheel for themselves. Now, through this book, any programmer can
have many of the benefits of apprenticeship.
McConnell covers everything from a practical standpoint. Nothing is
beneath his notice. He considers the maintainability of different
ways of formatting comments. He enumerates common confusing naming
practices and shows how to improve on them. He shows the flaws in
common techniques for indenting programs and suggests a better way.
McConnell tries to bring in the results of academic research. For
example, as he tries to explain what distinguishes top programmers
from lower levels, he cites a study that shows that only 30% of an
average programmer's time is spent working alone. Such citations
appear throughout the book, usually accompanied by a "hard data"
icon in the margin.
I knew this book was exceptional when I got to the chapter on high
quality routines. In the late 1960s, before the structured
programming revolution, many of us grappled with issues of how to
organize our programs. McConnell's discussion of valid reasons to
create a routine is more thorough and clear sighted than any
treatment of that subject I've seen in the intervening 25 years.
There is so much in this book that it's hard to single out parts to
mention. Debugging is one of the areas that I think separate the
professionals from the amateurs. McConnell quite rightly ridicules
some common practices. He doesn't offer a magic formula, but he
tries to put you in the right frame of mind to approach the task.
His principal suggestion for further reading on debugging is Martin
Stitt's book (see Micro Review, February 93), a recommendation I
heartily agree with.
McConnell devotes a chapter to where to go for more information. His
top two "highbrow programmer journals" are our sister publications
IEEE Software and IEEE Computer. He doesn't mention Micro--a serious
oversight, but forgivable. His top ten list of books starts with
Weinberg's Psychology of Computer Programming (Van Nostrand
Reinhold, 1971) and Bentley's Programming Pearls (Addison-Wesley,
1986). He says he uses something he learned from Bentley every day
of his professional life.
McConnell treats one subject you might find surprising: personal
character. He applies the same hard-headed practical analysis to
intellectual honesty, discipline, and habits that he applies to
formatting code and naming variables.
What I like most about this book is that I agree with so much of
what he says. As a contract technical writer I see the inner
workings of many programming projects, both in large companies and
in small. I rarely encounter anyone who thinks like McConnell or
applies even a small part of what he says in this book. That's a
pity, and I hope this book helps to change the situation.
At the risk of repeating myself, I recommend that you go out and buy
this book. Set aside some time over the next year to read it
carefully from cover to cover. You'll be glad you did.
Richard Mateosian <srm -at- cyberpass -dot- net> www.cyberpass.net/~srm/
Review Editor, IEEE Micro Berkeley, CA