How To Take Notes

From ProgrammersNotebook:

I've tried keeping notebooks, but am not good at it. When I was younger, I had an excellent memory and remembered everything, so I never bothered writing anything down and never learned how to take notes. Now, because I am older, stupider, and/or doing more-complicated things, I forget everything. But I never know what to write down. Either I write down every single detail, in which case I spend more time writing notes than doing work, or I just write down the stuff I think is important, which I later find to be the wrong stuff. Any advice about principles to follow or books to read to improve note-taking?

By the way, my primary focus is on taking notes for a LogBook or ProgrammersNotebook. I don't have a problem taking notes during meetings and presentations. My main problem is taking useful notes about what I'm doing: it all seems obvious while I'm doing it, so I never know what I'm going to forget later and thus I don't know what to write down.

-- KrisJohnson

Taking good notes is definitely a learned skill. I improved greatly when I was hired by the Students with Disabilities Office to take notes for a hearing-impaired classmate. She was partly deaf, and needed to lip-read to follow a lecture. We were taking the same class, so I took notes for her. Here's what worked for me:

Liberal use of unordered and ordered lists.
Underline important terms first time they're used or defined. Create an abbreviation if it's going to be the major topic of the page (Mitochondria = Mt). Define the abbreviation at the top of the page for easy reference.
Outline by indenting. It needn't comply with a strict format, but you should be able to tell if something is a major topic, or a side comment.

The above three probably reveal why I like PythonLanguage so much. It works the way I think. Later when I kept a LogBook for my lab and field work, I learned the following steps:

Document the facts. Write down what you did. (Example: "Retrieved foo.py from CVS repository")
Don't write down how it was done, unless it was done in a non-standard way. (Example: "Copied foo.py to Laptop for review during flight.")
When you document a non-standard process, do so in a level of detail that you could recreate the steps from the notes. (Example: "Moved foo.py from laptop ~/project/foo.py to desktop ~/projectX/foo-revised.py. Ran diff, checked changes. Renamed foo-revised.py to foo.py, checked in foo.py.").
If the notes are meant for somebody else, make sure they know (or can reference) your standard processes.

-- SeanOleary

I have a (electronic) timer going off every 15 minutes to remind me to write a few words about what I'm doing right now. This seems to work OK. -- PaulHudson

I ran across something called the Cornell Method on the web. The technique is to draw a vertical line down the middle of the paper, and record everything as it is happening on the right side. Later, one reviews what was written and reduces it to summary points that are written on the left side. --KrisJohnson

''More .." http://www.usu.edu/arc/idea_sheets/cornell.htm

I started doing this about halfway through college, and it made my notes much more useful.

Note down the words that count. The peculiar words. And forget grammar for personal notes.

For about 30 years I've been using TonyBuzan's BrainMapping technique. A student named the results SpiderGrams? (SpiderDiagram). The result looks like a spiders web with the topic in the center. The lines/arcs/connections have words on them. Add pictures and color -- they help. A Semantic Net. A picture of a linked data structure. The result is an ugly mess. Keep them private.

To remember things: review, repeat, summarize, ... The brain stores information that you use and hides what you don't use.

For process recording and log books I used a simple alphabetic short hand. One letter for the 26 commonest words ( do, to, go, the, ...). Useful on a Palmtop too. Added math/logic Symbols. Plus some phonetics for the less common words. Problem: you have to use it to be able to read and write it.

--DickBotting

Most of what is said here works, but the most important aspect of note-taking hasn't been mentioned: Recopy and reorganize your notes ASAP, ideally immediately following the event. This forces you to immediately work mentally with the notes, further cementing them in memory; provides the best opportunity to remember an important detail; maps them into a more coherent semantic schema for you; etc. Think of it as refactoring ;-)

It is not the most fun thing to do, especially if the context of note taking was a three hour lecture, however it is one of the best things you can do if you want to actually learn whatever it was you took notes from. --BrianMcCallister

I've always found a SpiderDiagram (what TonyBuzan calls MindMaps) useful. I use them for just about everything as it allows me to keep adding more information and show the relationships between pieces of information without worrying about the order.

When I have to communicate the information in my SpiderDiagram/MindMap to other people I then convert it to an Outline. You just go around the MindMap numbering all the spokes and soon you have a nice orderly outline. To paraphrase DavidParnas we don't design things via a rational process but we can tidy things up later so that it looks like we did. --AdewaleOshineye

They're more useful for organising other notes than for taking notes in the first place, I've found. And they also require you to have a pretty good idea of the central concept and the hierarchy of what's important and what's related to what. Which is often the case...

I've found the following technique works well for me when trying to capture spoken presentations:

Don't write anything down unless it's important. In other words, most of what you should do when taking notes is listening and understanding rather than writing.
Capture ideas that just occur to you as well as what's important in what's said. Even if they're entirely unrelated. This gives you context for understanding where you were at, and relieves you of the burden of trying to keep something else in mind than what's said.
Leave a lot of white space. You'll need it.
Try to maintain a linear flow of ideas in what you write down. Go back and fill in ideas where they fit in this flow.
Where the flow becomes graph-connected, use different kinds of arrows to capture different kinds of dependency. Temporal dependency, implication, equivalence, inheritance, etc.

I've used this to good effect with speakers who are very non-linear in their presentations, but it works well with orderly speakers too. The effect is that you seldom need to go back to consult your notes - they become more an aid to learning on the spot than an aid to memory later. Then when you do go back it's easy to put yourself back into the flow of consciousness you were experiencing when taking the notes. --PeterMerel

Also note the advantages of experimentation. Try note-taking for awhile, then review your work. If it isn't useful, try to figure out what doesn't work and change it. This can be quicker than an attempt to learn the "best" way to take notes beforehand.

How's this for a practical idea. Each group has a look at who takes the best notes. That person is then designated note taker, leaving the others to take notes or actually listen as they see fit. The note taker then has the option of asking the others questions to supplement his notes, which he then shares by way of copying. Sedobah

An observation - the method cited by Sedobah has been shown to be effective by IBM personnel. In meetings between IBM staff and customers, one IBM person would be designated note-taker, capturing both meeting content and personal observations (e.g.,'Cust seems happy about this'), thus freeing others to participate fully in discussions. Bill Reith

See http://wiki.43folders.com/index.php/Note_taking , WritingTheRightThingsDown, ProgrammersNotebook, LogBook, PreservingHistory?