From the Editor
IEEE Software, Vol. 15, No. 6, November/December 1998
How To Read A Technical Article
How to Read a Book by Mortimer J.
Adler stayed at the top of the nationwide best seller list for more than a
year when it was originally published in 1940 (Simon & Schuster). Adler
brought his experience as long-time editor of Encyclopedia Britannica to
bear on the project. Revised and updated in 1972, the book is still a
tremendously practical guide to the various kinds of reading we do both
personally and professionally. Adler includes sections on general reading as
well as specialized sections on reading fiction, history, philosophy,
science, and mathematics.
Reading Levels
Adler differentiates between 4 levels of reading.
"Elementary reading" is the most basic reading and is characterized by
learning to recognize individual words on a page. "Inspectional reading" is
a more advanced level of reading, which is characterized by trying to get
the most out of a book or article within a given amount of time. "Analytical
reading" is still more advanced, and is characterized by trying to get the
most out of a book or article with an unlimited amount of time. "Syntopical
reading" is the most advanced form of reading and involves reading sets of
books or articles on a common topic together in a way that allows you to
extract information that might or might not be present in any of the
individual materials studied.
Adler describes several techniques a person can use to read
a book or article quickly for Inspectional reading. You might think of this
as systematic skimming. He suggests that you first study the title. What
does the title tell you about the kind of book or article it is? If it’s a
book, next study the table of contents. What subject areas are covered? What
is the book’s emphasis? Can you infer the author’s main points from the
table of contents? Next, read the preface. In a well-written preface, the
author will summarize why the book was written, who the book was written
for, and what you should expect to get from reading it. Study the book’s
index. The table of contents tells you what the author planned to talk
about, and sometimes the index tells you what the author actually did talk
about. After that, study the introductory text in each chapter, and then dip
into the first and last chapters of the book.
Technical articles are a little more difficult than books
in that they don’t typically include tables of contents, indexes, and so on.
For technical articles, you might consider reading the abstract,
introduction, and conclusion, then reading the introductory text in each
section.
If what you’re after is a general understanding of the main
points of a book or article rather than the detailed logic, Inspectional
reading may be the only kind of reading you’ll need to do. If you later need
a more detailed understanding of the book’s contents, your Inspectional
reading will have prepared you to find that information quickly. Prior to
reading this advice in How to Read a Book, I had always felt a little
guilty about not finishing a book. But Adler makes a strong case for not
going beyond Inspectional reading unless you need to. I found his advice
liberating; he told me that it was acceptable to read a book in this way,
and gave me a systematic method for doing something I had previously been
doing only haphazardly.
In case you do need to perform Analytical reading,
Inspectional reading prepares you for that. In reading a book or article for
understanding rather than just for information, you need to both acquire an
understanding of the way the author has organized the subject matter and an
understanding of the subject matter details. By jumping into the details
first, starting at page 1 and reading through to the end, you have to
acquire both of these kinds of knowledge simultaneously, which is very
difficult. By performing Inspectional reading first, you acquire an
understanding of the organizational framework quickly, and you can then fit
the details into the framework during your more detailed reading of pages1
to n.
Questions First, Answers Second
One of the rules of Analytical reading is that you should
try to state as clearly as possible the problem that the author has tried to
solve. In reading a paper submitted to IEEE Software, I always ask,
"why would Software’s readers care about this paper? Does it address
a real problem? In what specific way will it make our readers’ lives
easier?"
A related idea is that the more you engage in a dialog with
the author of a book or article, the better your understanding is likely to
be. If you’ve performed Inspectional reading first, you will probably have a
long list of questions for the author: "Why did you include subject X and
not subject Y? Do you think subject Y is unimportant? Is it outdated? Did
you simply not know about it? Does it really make sense to discuss subject B
before subject A?" In addition to such specific questions, Adler proposes
four generic questions that you can ask of each book or article you read:
- What is the book or article about as a whole?
- What is being said in detail, and how is it being said?
- Is the book or article true in whole or in part? You have to read the
material carefully enough to answer the first two questions before you
can answer this one.
- What of it? How does the author’s conclusion relate to you or your
work?
As Editor of Software, I have a more specific set of
questions I ask of each manuscript that’s submitted. Bearing these questions
in mind helps me understand what the article is about.
First, I have to assign each submitted article a "CR Code,"
which is a classification scheme IEEE Software uses to categorize all
submitted articles and send them to reviewers who have indicated an interest
in the same subject. Often, I can assign the CR code simply by reading the
article’s title, abstract, and conclusion. The first question I ask, then,
is a variation of Adler’s "what is this about?" My question is, "What is the
article’s alphanumeric CR code?" If I have difficulty assigning a CR Code,
that is my first clue that the purpose of the article might be unclear,
though sometimes it is our classification scheme that is unclear.
The second question I ask of each submitted article is
"What genre is it?" Every article submitted to IEEE Software is assigned one
of the genres that are highlighted in this issue’s focus, and those genres
are later used to guide the peer reviewers’ review of the article. The genre
designation amounts to a partial answer to Adler’s question of "What of it?"
Is the article a How To? A Case Study? A Tool Report? A Practice Tutorial? A
Research Tutorial? An Applied Research Result? An Experience Report? An
Essay? Or does it not fit neatly into any of our defined genres?
When the peer reviews for an article come back, I have to
consider each of Adler’s four questions in determining whether an article is
suitable for publication. I rely on reviewer comments to help me determine
whether the article is "true in whole or in part" and whether it will be
useful to our readers. If we receive an article in a specialized area, such
as an Applied Research Report, the article’s vocabulary might be too
specialized for me to understand completely. I have to revert to "elementary
reading" for that kind of article because I struggle just to understand some
of the individual words.
Because IEEE Software is a magazine, not a journal,
before publication we try to rework articles of this kind so that our
typical reader will be able to read the article at the Analytical level.
Before that happens, reviewers who know more about the specialized subject
matter than I do help me to determine the answer to Adler’s second question,
"What is being said in detail, and how is it being said?" Sometimes, the
reviewers conclude that nothing is being said! In that case, we reject the
article. Other times, sometime valuable is being said but it isn’t being
said clearly enough for our magazine, and in those cases we work with the
author to revise the material so that our typical reader will be able to
benefit from the author’s insights.
Editor: Steve McConnell, Construx Software, 11820 Northup
Way #E200, Bellevue, WA 98005.
E-mail: steve.mcconnell@construx.com
- WWW:
http://www.construx.com/stevemcc/
