Learning to learn

It might sound a bit stupid, but I just realized that a better reading strategy could help me learn faster, almost three times as fast as before.

To enter a research field, we sometimes have to read tens of research papers. We could alternatively read summaries like textbooks and survey papers, which are generally more comprehensive and more friendly for non-experts. But some fields don’t have good summaries out there, for reasons like the fields being too new, too narrow, or too broad.

Since original research papers are more accurate and more up-to-date than summaries, it’s important for us to read these papers as we enter the field. Yet, these papers are usually written for experts that already know a lot about the background. In other words, unless a paper opened up a new field, the paper would assume that readers already know about many terminologies and implications — which we don’t yet know about — and use them without explaining much.

Apparently, inexperienced researchers like me can often find papers hard to understand. We can easily end up with a sad situation: devoting lots of time on lots of papers, trying to summarize a big picture of the field by understanding each major contribution, but, at the end of the day, unsure whether our impressions are accurate or not.

A reading strategy seems to have helped me get out of this endless devotion of time.**** The strategy has two parts.

Part 1. Taking good notes and keeping them organized.

Where we store information greatly affects how we access it. If we can always easily find some information — from Google or our own notes — then we can pick it up quickly, even after forgetting it. This observation can make us smarter. Back in highschool, when I kept all the unmastered knowledge in a special notebook (错题本) and reviewed this notebook before exams, I boosted my performance.

Let’s do the same when reading papers. Now I keep searchable notes as follows:

  • For every topic, create a document that contains the notes for all papers on this topic.[1]
  • For each paper, take these notes: summaries, quotes, and sufficient bibliographic information for future lookup.[2, pages 95-99]
  • When reading a new paper, if it cites a paper that I have already read, review the notes for the cited paper. Update the notes as needed.

This way, we won’t lose what we have read and learned.

Part 2. Skipping technical sections for 93% of the time.

Only 7% of readers of a paper will read its technical sections.[1] Thus, if we want to read like average, it might make sense to skip technical sections for roughly 93% of papers that we read. For example, consider reading each paper like this:

  • Read only the big-picture sections — abstract, introduction, and conclusion;
  • Scan the technical sections — figures, tables, and the first and the last paragraphs for each section[2, pages 76-77] — to check surprises;
  • Take notes;
  • Done!

In theory, the only 7% of the papers that we need to read carefully would be those that we really have to know well.

These tips work quite well for leisure reads, but applying them to serious research can be awkward, as we hope to be confident about our understandings. Often, I was worried by inaccurate impressions and was compelled to read papers more carefully than the above tips suggest. I had two concerns:

  • Some papers’ big-picture sections oversell. So I would read the technical details until understanding their limitations;
  • Some papers’ big-picture sections are too vague to be wrong and convey little information. So I would read the technical details to learn, concretely, how and why the techniques worked.

Luckily, these two concerns are not that bad. At least, they may be smaller than the problem of reading too slowly.

When we read technical sections, time drains quickly. If a paper is poorly-written*, it is almost impossible to understand the paper’s techniques satisfactorily in reasonable time. So if we compare our status before and after reading the technical sections, we’ll find that the knowledge gain is quite small compared to the additional time devotion.**

Compare this situation with the situation if we used another strategy: spending the time reading several other papers’ big-picture sections. Big-pitcture sections are usually written more clearly than technical sections. Thus, we we will learn more, though different, knowledge now than if we read the technical sections of one paper.

The key question is: which knowledge is more important? Should we spend time to get a deeper and more accurate understanding of a paper’s technical implementation, or to get a broader but less accurate understanding of several other papers? Time is limited, and we have to choose.

Naturally, the answer depends on how much we need to know about the paper. If we need to discuss the paper as related work, sure, we’d better read their techniques to understand their limitations more accurately. On the other hand, if we want to get only the big picture of the research field and have tens of other papers on the to-read list, then we might achieve the goal much faster by reading other papers’ introductions instead.***

In short, skip technical sections. They are not worth the time.**

This new strategy seems to have helped me learn much faster.**** And it worked instantly, without me having to improve the English level whatsoever!

* A recent experience made me realize that there may be more poorly-written papers in the world than I had thought. I came across four papers[3][4][5][6] that solved the same problem and were, incidentally, all published in the same conference at the same time. Since they have similar stories, their big-picture sections are almost paraphrases of each other. But some of these papers were much harder to read than others. Apparently, these four papers differed in their writing quality. Some authors omitted necessary logical connections, making their paper hard to understand quickly. Now it seemed that my past reading slowness was not all my fault, neither (a) that my English was poor nor (b) that I didn’t know the field well enough. Rather, the biggest problems might have been (a) that I couldn’t identify bad writings and (b) that I needed a better strategy for reading poorly-written papers.
** This discussion is on poorly-written papers. On the other hand, well-written papers are still unconditionally fun and productive to read! I can’t resist learning from well-written papers, even if it takes some time.
*** Remember that we can always revisit this paper in the future. Just remember to take notes as in Part 1 so that the future revisits will be easier.
**** Apply this strategy based on the field, the goals, and the current stage. See a later post, Learning curves.

[1] Lecture on literature review by the MIT Writing and Communication Center.
[2] Booth, Wayne C., Gregory G. Colomb, and Joseph M. Williams. The Craft of Research. University of Chicago press, 3rd edition, 2008.
[3] Jong-Deok Choi, Manish Gupta, Mauricio Serrano, Vugranam C. Sreedhar, and Sam Midkiff. 1999. Escape analysis for Java. In Proceedings of the 14th ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications (OOPSLA ’99)
[4] Bruno Blanchet. 1999. Escape analysis for object-oriented languages: application to Java. In Proceedings of the 14th ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications (OOPSLA ’99)
[5] John Whaley and Martin Rinard. 1999. Compositional pointer and escape analysis for Java programs. In Proceedings of the 14th ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications (OOPSLA ’99)
[6] Jeff Bogda and Urs Hölzle. 1999. Removing unnecessary synchronization in Java. In Proceedings of the 14th ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications (OOPSLA ’99)

Added references to the four papers on the same topic.
Added a footnote that links to a later post.