Issue: November/December 1998 | PDF

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:

1. 1. What is the book or article about as a whole?
   2. What is being said in detail, and how is it being said?
   3. 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.
   4. 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  |  More articles