Aimee's Study Notes

It is updated automatically after each commit to the org-notes repo. It was last updated on Oct 09, 2021 05:00 UTC.

# How to Read and Write

tags: writing

### Content

The Barbell Method takes this into account by integrating your reading habit into your knowledge work with two steps:

Read the book. Read swiftly but don’t skip any parts unless they make you vomit or put you to sleep. Mark all the passages that stand out and contain useful, interesting or inspiring information.

Read the book a second time. But now you read the marked parts only. This time you make notes, connect them to past notes (Zettelkasten Method!) and think about what you’ve read. Make mindmaps, drawings, bullet points – everything that helps you to think more clearly.

The quality of the book will now determine how much time you invest in it. Sometimes, a book is not that important and only provides a few shallow pieces of information. The second step could only take a very short period of time. But a good book is dense.

True reading is not a passive process in which you just create an influx of information. It consists of deep processing, thinking and writing on what you have read and interconnecting it with you already know.

Only the three parts combined, reading, thinking, and writing, produce a true change in your brain and make you a better thinker. To write about what you read is important even if you don’t aim to write books on something. Still, you have to write if you want to think properly. Still, you have to write to process information properly.

Don’t try to impress anyone with things you don’t have invested energy into.

At last, you are what you practice regularly. You are your habits. If your habits don’t include to really gnaw on ideas and concepts, you won’t sharpen your mental teeth. So if you want to be able to think deeply and properly, practice it.

The Zettelkasten Method is designed to serve several different purposes:

• Optimize the amount of information you process. You should read a lot.
• Produce an archive which consists of true knowledge, not just a collection of half-understood bits of random points.
• Learn to think deeply and thoroughly by making it a habit to practice it.

THE THREE-PASS APPROACH

The key idea is that you should read the paper in up to three passes, instead of starting at the beginning and plowing your way to the end. Each pass accomplishes specific goals and builds upon the previous pass: The first pass gives you a general idea about the paper. The second pass lets you grasp the paper’s content, but not its details. The third pass helps you understand the paper in depth.

The first pass is a quick scan to get a bird’s-eye view of the paper. You can also decide whether you need to do any more passes. This pass should take about five to ten minutes and consists of the following steps:

1. Carefully read the title, abstract, and introduction
4. Glance over the references, mentally ticking off the ones you’ve already read

At the end of the first pass, you should be able to answer the five Cs:

1. Category: What type of paper is this? A measurement paper? An analysis of an existing system? A description of a research prototype?
2. Context: Which other papers is it related to? Which theoretical bases were used to analyze the problem?
3. Correctness: Do the assumptions appear to be valid?
4. Contributions: What are the paper’s main contributions?
5. Clarity: Is the paper well written?

Incidentally, when you write a paper, you can expect most reviewers (and readers) to make only one pass over it. Take care to choose coherent section and sub-section titles and to write concise and comprehensive abstracts. If a reviewer cannot understand the gist after one pass, the paper will likely be rejected; if a reader cannot understand the highlights of the paper after five minutes, the paper will likely never be read.

In the second pass, read the paper with greater care, but ignore details such as proofs. It helps to jot down the key points, or to make comments in the margins, as you read.

To fully understand a paper, particularly if you are reviewer, requires a third pass. The key to the third pass is to attempt to virtually re-implement the paper: that is, making the same assumptions as the authors, re-create the work. By comparing this re-creation with the actual paper, you can easily identify not only a paper’s innovations, but also its hidden failings and assumptions.

This pass requires great attention to detail. You should identify and challenge every assumption in every statement. Moreover, you should think about how you yourself would present a particular idea. This comparison of the actual with the virtual lends a sharp insight into the proof and presentation techniques in the paper and you can very likely add this to your repertoire of tools. During this pass, you should also jot down ideas for future work.

This pass can take about four or five hours for beginners, and about an hour for an experienced reader. At the end of this pass, you should be able to reconstruct the entire structure of the paper from memory, as well as be able to identify its strong and weak points. In particular, you should be able to pinpoint implicit assumptions, missing citations to relevant work, and potential issues with experimental or analytical techniques.

I’ve used this approach for the last 15 years to read conference proceedings, write reviews, do background research, and to quickly review papers before a discussion. This disciplined approach prevents me from drowning in the details before getting a bird’s-eye-view. It allows me to estimate the amount of time required to review a set of papers. Moreover, I can adjust the depth of paper evaluation depending on my needs and how much time I have.

If you are reading a paper to do a review, you should also read Timothy Roscoe’s paper on “Writing reviews for systems conferences”. If you’re planning to write a technical paper, you should refer both to Henning Schulzrinne’s comprehensive website and George Whitesides’s excellent overview of the process. Finally, Simon Peyton Jones has a website that covers the entire spectrum of research skills.

## How to write

Timothy Roscoe’s paper on “Writing reviews for systems conferences”. This is the paper worth reading many times, and follow his practice.

*First of all, summarize the paper. * Give a neutral description of what you think the paper is about, where the authors are coming from, why they view the problem as important, and what they’ve done. This is a great way to start writing a review, particularly when you’re not sure how to get started.

Second, state what you think the contributions are. It’s rare to find a paper that completely fails to make any contributions, but it’s much more common to find one that makes no useful contributions, or contributions that turn out to be flawed. In any case, state what the authors think the contributions are, or, if you think there’s a contribution you think they’ve missed, what it is. A surprisingly common mistake among paper authors is to fail to state the contribution - if that’s the case, gently point this out (see “Tone” below), but try to fill it in.

Next, give your specific comments on the paper by working through the scribbles you made on first (or second) reading. Often you may find your opinion has changed in the meantime, which is fine (you may even have learned something!). Some reviewers like to separate their comments into technical discussion, and then small points like typos and other mistakes, often referred to as “nits”.

Finally, provide some kind of conclusion at the end. If you like, summarize the good points and bad points separately, but the important thing is to give a brief recommendation for the paper and your reasons for it.

Consequently, tone is important.

Rather than saying “this paper doesn’t cite Multics, which did everything you do and more”, it’s better to say something like “This paper reminded me of Multics, which seems quite similar. I would find the paper more persuasive if it stated what the authors do over and above Multics.”

Also bear in mind that, in all cases, there is a still a remote possibility that you’ve misunderstood the paper. Hence, a flat assertion like “The algorithm given in the paper breaks in the presence of Byzantine faults” is risky, and may be unfair to the authors. It’s better to write “The description in the paper left me worried that algorithm breaks in the presence of Byzantine faults.”, preferably followed by a sketch of why you think this is the case.

Conclusion

Writing a good review is important: it helps the authors do better work, it helps you to learn more about the subject being reviewed, and it makes you look good in front of your peers. Surprisingly, it can also be fun – even writing a review for a really bad paper can be rewarding if it forces you to explain concepts afresh in a new context.

Notes on writing well by Michael Nielsen

On note-taking: Something I wish I’d understood earlier is how important it is to get good at note-taking. It is not trivial to do well. Rather, it is something that one can get better and better at. The payoff of improving is that it makes writing far easier. The better your notes, the easier the writing will be. There are several elements to it: (1) Primary note-taking; (2) Queueing; (3) Refactoring and organization. You need to get good at all.

In “Structure and Interpretation of Computer Programs”:

• “Building Abstractions with Procedures”
• “Building Abstractions with Data”
• “Modularity, Objects, and State”
• “Metalinguistic Abstraction”
• “Computing with Register Machines”

Chapter titles 1, 2 and 5 are verb phrases, while 3 and 4 are noun phrases. I prefer the more active titles, perhaps for the obvious reason that they create more of a sense of going someplace!

Beware classic style if you’ve not yet mastered a subject: Sometimes, you wish to write about a subject, even though you haven’t yet mastered that subject. It is difficult to write on such a subject in classic style, because the assumptions of classic style very nearly imply mastery. It is easier to instead slip occasionally into a personal style, explaining your exploration of the subject, and the limits of your knowledge. In such cases it may work to use a hybrid style, in which you alternate the personal with the classic. Feynman occasionally uses this style, either to explain his own thinking, or to explain the hypothetical thinking of others.

How to write usefully

This site is generated with ox-hugo for Emacs/Org-mode + hugo-bare-min-theme [Aimee's Study Notes]