I don't know how to say this delicately, so I won't: I'm having trouble distinguishing this book from the disjointed ramblings of a mad man. The RANDOM capitalization of VERY IMPORTANT WORDS! combined with the "snake-oil sales pitch" style of writing doesn't do this work any favors, but it's really the content where this comes up short. Apart from the premise of mapping every thought, no viable strategy is offered achieve this.<p>What's the solution here? After a few years you end up with huge boxes full of notes, some of which have been appended over and over? Mind maps rarely scale when done with software, paper note-taking just makes it all the more hopeless.<p>And really, why be so obsessive about conserving every little thought like your stream of consciousness holds some big revelation at the end? That's not how it works. Forgetting and scrapping things is an important part of organizing the mind and the output it produces. On a meta level, this book illustrates very well what happens if that doesn't work.<p>If we're building a system with the goal of swapping out thoughts and memories, it really has to augment the brain in some fashion. Refining relations between concepts is something the brain is already good at, it would make more sense to help it along in areas where the brain sucks: keeping lists and details. Seriously, open an Evernote account or something and don't worry too much about organization and preservation.<p>I'm really sorry if this sounds mean, it's not supposed to.
Thanks for posting this.<p>Maps make amazing summarization/summary capturing tools. I used to unknowingly use them during my college days. One of the main reasons why I spent 1/10th the time yet scored the same as my classmates was maps. I would practically convert each chapter into a map, and merely crawling though a map was more than sufficient for any kind of a revision.<p>In our industry maps make wonderful testing tools. Lets say you want to test X, write down a map of each functionality, then write down further nodes, which basically is what could possible go wrong or right with each node(Each of this becomes a separate node). For each node you expand, stress the node bring out more test nodes until you can't stress any node anymore.<p>The resultant map will be nearly the best test cases you can come up with.<p>Now do this before you start coding, and what you will get is all the scenarios you need to handle to make the code bug free.<p>Additional tip, avoid using map software. Best tools for this kind of work are paper/pen or whiteboard/marker.<p>I've been using this strategy to write C code for embedded systems. And it works like a charm.
That's very interesting. I foresee a problem with capacity. If you keep everything around eventually you won't be able to move anymore. I'm so happy that I'm beginning to forget some of the stuff from my childhood, to keep carrying that along forever seems like a huge weight. Forgetting is just like remembering: a blessing and a curse at the same time. It would be really nice if our minds could actively forget something (like a file delete on a file system), right now it seems to be mostly governed by some caching rule where the last stage of the cache is /dev/null.<p>By committing it all to paper (and presumably, by re-reading it) you fire up all those neurons periodically which will lead to you thwarting the garbage collection process. As a consequence eventually you'll either run out of room or possibly end up with mental issues (inability to acquire new stuff or inability to focus due the large number of associations running out from each thought you have).<p>There is a cost associated with this map making, still, I'm very much tempted to try it to see what the positive effects are.
>I wrote a book on a notekeeping system: How to make a complete map of every thought you think.<p>>My notekeeping system has since dramatically changed, and is now, primarily, a simple chronology with some discipline connected to it.<p>From the author's site.
This is an interesting thought about the disadvantages of software text editors:<p>"A long time ago, I stored all of my thoughts in a computer text file. It was actually an AWESOME system. The computer has so many advantages that the paper world doesn't. [...]<p>For all this awesomeness in the computer, you are unconsciously pulled into a problem:<p>ALL OF YOUR TEXT looks EXACTLY THE SAME.[...]<p>YES, YES! I CAN HEAR YOU COMPUTER-PEOPLE'S COMPLAINING. ``But you can use FONTS!'' But you can make it Bold! But you can make it Italics! yes! Yes! YES! I know it! You CAN do all those things.<p>But that doesn't make it FAST. In keeping notes, you don't want to constantly be dicking around with your UI. You want to be able to JUST WRITE.[...]<p>So, by contrasting with the computer, I have described the kinds of things you want to concentrate on in your notebook. USE DIAGRAMS EVERYWHERE. They are FAR better than coercive linear text. And USE VARIABLE WRITING STYLES. Write sloppy, write neat, and everything in between. It communicates to you. Use shorthand and abbreviation. Know Gregg's script? Use that when it suits you."<p>In general I feel that this whole text/book could use a lot of editing. It's intentional of course, as the author says himself he just spits out the text without going back. Still, at a length of >100 pages it is frustrating. Thank you anyway for posting, it is very inspiring!
I remember reading this when he first posted and finding quite a few good insights, some expressed a little idiosyncratically but I think that's in the nature of people doing original thinking. It's stream of consciousness but that fits with his goal to capture and curate his thoughts. The section that begins<p><pre><code> Here's a Speed List: "Electronic Collaboration"
</code></pre>
in chapter 6 Intra-Subject Architecture (see <a href="http://speakeasy.org/~lion/nb/html/doc007.html" rel="nofollow">http://speakeasy.org/~lion/nb/html/doc007.html</a> )
contains good insights into how to leverage email, wikis, and mindmaps.
I've seen this one before and it looks interesting; but I've got a good enough system of notes. What I'd really like to do is keep a engineer's notebook about my software and record things I tested, what I thought, and the results, but I don't quite know where to start or what sort of system would work well for me. I guess I should be A/B testing that.
I haven't looked at the book yet, but there is an obvious problem here with running out of stack space....unless you have some way of avoiding thinking about your note taking while you do it.