Get more out of your startup reading(swombat.com)
swombat.com
Get more out of your startup reading
http://swombat.com/2011/1/11/get-more-out-of-your-startup-reading
9 comments
I had hoped that people would do things like that (summaries, discussions) on SqueezedBooks.com but now I've sold it (although I retain some interest in it) and am not sure where it's going to go right now.
That looks like a great site with lots of good content. Does it bring in much revenue?
Nope.
How did you manage to sell it then? Much traffic?
Yeah, it gets a reasonable amount of traffic, and ranks fairly well on Google for summaries of some of the books. I was never able to do a good job of translating that into active participants, advertising dollars, or Amazon referral fees either. Part of the reason I sold it and retained some interest in it is to see if someone else could do a better job.
I've noticed a few interesting book sites recently -
http://7bks.com
http://www.hn-books.com/
http://anynewbooks.com/
http://bookflavor.com
Maybe you could partner up with one of them?
http://7bks.com
http://www.hn-books.com/
http://anynewbooks.com/
http://bookflavor.com
Maybe you could partner up with one of them?
I'm open to suggestions and partnerships (for AnyNewBooks.com).
I take notes, but mainly from the books I read. I did see a site that gave a condensed version of business books, but I can't seem to find it off-hand. What I think would be useful would be a site like Read Later, but where you could annotate and others could find your notes prior to reading the full article. Personally I never read a HN article before I read the notes to see whether its worth reading!
I used to read HN comments before reading articles, but I don't do that much any more because I find the top comments on HN often miss the point of the article. The top comments are almost always criticising the article, which is OK because "good post" comments are mostly boring. But the criticism is often due to misunderstanding the author.
Most articles are not worth reading because they don't have much substance; so there's not much point reading comments about them. For the very little original and interesting writing out there, I prefer to read it before reading any comments.
Most articles are not worth reading because they don't have much substance; so there's not much point reading comments about them. For the very little original and interesting writing out there, I prefer to read it before reading any comments.
Is this the site you can't find? http://sivers.org/book
Wow, it's not but that's a great find. Thank you!
Taking notes definitely helps. The problem is I always forget to revisit them. That's exactly why me and some friends built thoughtback.com. It's a micro-journaling tool with mac and web apps that automatically re-exposes you to your thoughts.
PS - I'm really not sure if it's appropriate to post a link to a service that's relevant to the article in the comments if I made it. Should I not do this again?
PS - I'm really not sure if it's appropriate to post a link to a service that's relevant to the article in the comments if I made it. Should I not do this again?
In my opinion, the most difficult part of this kind of endeavor is to continuously update the site with insightful summaries of the articles/books.
He does describe an important problem, but, gee, I thought that everyone on Hacker News long since had a good solution if only as a special case of how they keep track of information more generally! :)!
But, not for the first time, apparently I was wrong!
So, here's my solution to the problem described in the blog, my 'Personal Information Management 101 for Dummies'. I describe my solution in four parts below:
(1) Text
I like text, in English.
There is a fundamental reason: So far there is essentially only one way to communicate information, and that is text, e.g., English, hopefully in complete sentences in well organized paragraphs. Sorry, guys, seriously, in English, that's the only way that works. Math? Actually it is not an exception (I omit details on just why). Mathematical physics? Engineering? Computer science? The same.
So, text is necessary.
Nicely enough, simple text is also sufficient (unless are writing math in which case it's also very nice to have Knuth's TeX).
So, text is necessary and sufficient for communicating all information except for math where also need, say, TeX.
Graphs? Tables? Pictures? Those are often helpful, nearly always not crucial to the information, and can never replace text. Computer language code? Similar. And, yes, computer people, code can never replace text in complete English sentences.
So, fantastic news: Now one of the things current computing is the very best at is handling simple text. FANTASTIC. So, I exploit that fantastic news.
So, while I have a long list of three letter file extensions on my computer's hard disk, I make sure, usually with minimal effort, that nearly all the 'information' is in just simple text.
By analogy, simple text solves the Tower of Bable problem of many different sources of information; even if keep a copy of the original, just convert it all to simple text.
(2) Text Editor
Okay, in a kitchen, two of the very best tools are a quite sharp French chef's knife and a maple cutting board.
Well, in close analogy, in handling text, the best tool is a good text editor. I use KEdit on Windows XP, and before converting to Windows used KEdit also on OS/2 and MS/DOS. Before that I used the very similar XEDIT on VM/CMS. KEdit is a good text editor.
KEdit is by a wide margin my most heavily used tool in computing.
While KEdit is a good (excellent?) text editor, in part its glory is its macro language, basically M. Cowlishaw's elegant Rexx. So, in a cooking analogy, I can have a macro for slicing carrots -- given a bunch of carrots, type the name of the carrot macro, and, presto, washed, peeled, sliced carrots.
For spell checking, I use Aspell that comes with at least one TeX distribution. Aspell is terrific. Since, really, I want just one personal 'addendum' dictionary, I use Aspell for as much as possible of my spelling corrections.
Related is that I use ObjectRexx as a text window scripting language, and, yes, it can drive KEdit.
So, I use KEdit for as much as possible of my typing, for forum posts such as this one, e-mail I send, software for KEdit macros, scripts, Visual Basic .NET, C, Fortran, T-SQL, HTML via ASP.MET, input to Knuth's TeX, own notes of wide variety, etc.
One of the best single ways to get work organized, lacking anything else, is just time and date. So I have little macros that insert time and date lines wherever useful. In a programming language, the line is inserted as a comment in that language.
In a text file, if a line has a tree name or a URL, then one keystroke tells KEdit to 'do the right thing', usually 'open' that file. So, my programming source code is awash in such 'links'.
Yes, just a few lines of the KEdit macro language can use old serial port COM1 to send to my FAX modem card an old AT code with a phone number. Since my land line desk phone goes through that FAX modem card, one keystroke in KEdit dials the phone number. Darned useful.
Once I wrote some simple POP3 e-mail software and used it for years. Then, if I was editing a file in KEdit and that file had a line with an e-mail header line, e.g.,
Date: Wed, 12 Jan 2011 01:01:38 -0500
then one keystroke in KEdit would display that e-mail message. Darned useful, and I need to get back to something like that.
Yes, one reason simple text and KEdit work so well is that such text is easy for both me and the macros I write.
(3) Taxonomic Hierarchy
As we know, going way back through MS/DOS and Unix to Multics, now hierarchical file systems are a standard feature of computing.
So, I use the hierarchical file system to implement a 'taxonomic' hierarchy of information in my work. Just with the hierarchy, I can find nearly anything I have quickly.
In each file system directory (no, I avoid 'folders'), say, with name x, there is a file x.DOC, yes, in plain text, not from Microsoft's program Word, that indicates the purpose of the directory and documents the files in it.
For a file I downloaded, typically I have the original URL, its title, some of its text, and some of my notes on its relevance to the purpose of the directory.
This DOC file can also record some relevant cross references among files and directories on my hard disks.
So, the top two nodes in my taxonomic hierarchy are PROJECTS and TOPICS. The first is for work that is really just mine, and the second is for information from others. Directory PROJECTS has 59 subdirectories, and TOPICS has 65. Yes, I have some simple command line 'tree walking' scripts I like much better than anything from Microsoft.
Yes, I use text windows and command lines heavily -- again, they are easy for both me and the scripts I write.
(4) Directory Listing.
The scripting language ObjectRexx has a function SysFileTree that will give an 'array' with one array 'component' for each file or directory in a file system subtree along with time and date last changed, length in bytes (modulo 232, for files), the usual file system 'attributes' such as system, hidden, archived, read-only, and directory, and the fully qualified tree name.
I have a simple script that writes this 'array' to a file, typically in the root directory of the file system subtree it describes, with one line for each array 'component'.
The file is in 'fixed fields' and, thus, in KEdit is easily sorted on any of the fields.
And, of course, KEdit has terrific means of 'selecting' lines from the file, and it is easy to write macros, even for just one use, for much more in 'selecting' desired lines.
This file is often very useful for finding things and manipulating files and directories, especially when further processed with macros or scripts.
(4) Facts
I also have a file, and, now, really a small 'system', for ready access to 'facts' or little points someone with a phenomenal memory would just keep in their head.
The 'system' is dirt simple and works GREAT. It's shocking, and even intriguing, how successful such a simple system can be.
Yes, the whole thing is used and maintained using KEdit and with a grand total, please sit down for this, of two (2) macros particular to Facts.
The file is SMALL: It currently is just 812,965 bytes, 26,915 lines, 1,395 separate 'fact' entries, since
Friday, September 2nd, 2005.
That is, 1,958 days, for about
1,395 / 1,958 = 0.71
facts per day.
A typical fact entry is:
==========================
:Created at. 21:18:47 on Tuesday, January 11th, 2011.
:Keys. viral CloudSponge
CloudSponge is supposed to help viral growth.
With promo code TWIVC from Mark Suster, might get freebe for 3 months.
==========================
So, for the problem in the blog post, as I read Hacker News, etc., if I find an article, blog post, fact, etc. that, as in the blog post, I believe might be useful to me, then I put some relevant data on my disk. For an HTML file, typically I will pick an appropriate directory in my taxonomic hierarchy, in a text window use my tree walking scripts to get to the directory, use a KEdit macro to pick a name for the file and put its tree name on the clipboard, have my favorite Web browser get the tree name from the clipboard and save the file as that tree name. Then I have another KEdit macro help me put an entry in the DOC file for that directory describing the file.
So, to find things, a first approach, which usually works, is just to do some tree walking in my taxonomic hierarchy.
If that fails, then using Microsoft's program FINDSTR (a weak version of a good version of the standard Unix program GREP -- there is likely a good version of GREP for Windows, and likely I should get one) is usually enough.
If I am really looking for 'information' on a topic, then, again, the taxonomic hierarchy is a good approach, the DOC files in relevant directories can be better, and my little system Facts can be still better.
Net, the problem in the blog post I believe I have solidly solved: I keep stuff, my own and from the Internet, and can find the stuff either as specific files or starting with just a topic.
As in a kitchen, a few, good, simple tools can be the best approach.
But, not for the first time, apparently I was wrong!
So, here's my solution to the problem described in the blog, my 'Personal Information Management 101 for Dummies'. I describe my solution in four parts below:
(1) Text
I like text, in English.
There is a fundamental reason: So far there is essentially only one way to communicate information, and that is text, e.g., English, hopefully in complete sentences in well organized paragraphs. Sorry, guys, seriously, in English, that's the only way that works. Math? Actually it is not an exception (I omit details on just why). Mathematical physics? Engineering? Computer science? The same.
So, text is necessary.
Nicely enough, simple text is also sufficient (unless are writing math in which case it's also very nice to have Knuth's TeX).
So, text is necessary and sufficient for communicating all information except for math where also need, say, TeX.
Graphs? Tables? Pictures? Those are often helpful, nearly always not crucial to the information, and can never replace text. Computer language code? Similar. And, yes, computer people, code can never replace text in complete English sentences.
So, fantastic news: Now one of the things current computing is the very best at is handling simple text. FANTASTIC. So, I exploit that fantastic news.
So, while I have a long list of three letter file extensions on my computer's hard disk, I make sure, usually with minimal effort, that nearly all the 'information' is in just simple text.
By analogy, simple text solves the Tower of Bable problem of many different sources of information; even if keep a copy of the original, just convert it all to simple text.
(2) Text Editor
Okay, in a kitchen, two of the very best tools are a quite sharp French chef's knife and a maple cutting board.
Well, in close analogy, in handling text, the best tool is a good text editor. I use KEdit on Windows XP, and before converting to Windows used KEdit also on OS/2 and MS/DOS. Before that I used the very similar XEDIT on VM/CMS. KEdit is a good text editor.
KEdit is by a wide margin my most heavily used tool in computing.
While KEdit is a good (excellent?) text editor, in part its glory is its macro language, basically M. Cowlishaw's elegant Rexx. So, in a cooking analogy, I can have a macro for slicing carrots -- given a bunch of carrots, type the name of the carrot macro, and, presto, washed, peeled, sliced carrots.
For spell checking, I use Aspell that comes with at least one TeX distribution. Aspell is terrific. Since, really, I want just one personal 'addendum' dictionary, I use Aspell for as much as possible of my spelling corrections.
Related is that I use ObjectRexx as a text window scripting language, and, yes, it can drive KEdit.
So, I use KEdit for as much as possible of my typing, for forum posts such as this one, e-mail I send, software for KEdit macros, scripts, Visual Basic .NET, C, Fortran, T-SQL, HTML via ASP.MET, input to Knuth's TeX, own notes of wide variety, etc.
One of the best single ways to get work organized, lacking anything else, is just time and date. So I have little macros that insert time and date lines wherever useful. In a programming language, the line is inserted as a comment in that language.
In a text file, if a line has a tree name or a URL, then one keystroke tells KEdit to 'do the right thing', usually 'open' that file. So, my programming source code is awash in such 'links'.
Yes, just a few lines of the KEdit macro language can use old serial port COM1 to send to my FAX modem card an old AT code with a phone number. Since my land line desk phone goes through that FAX modem card, one keystroke in KEdit dials the phone number. Darned useful.
Once I wrote some simple POP3 e-mail software and used it for years. Then, if I was editing a file in KEdit and that file had a line with an e-mail header line, e.g.,
Date: Wed, 12 Jan 2011 01:01:38 -0500
then one keystroke in KEdit would display that e-mail message. Darned useful, and I need to get back to something like that.
Yes, one reason simple text and KEdit work so well is that such text is easy for both me and the macros I write.
(3) Taxonomic Hierarchy
As we know, going way back through MS/DOS and Unix to Multics, now hierarchical file systems are a standard feature of computing.
So, I use the hierarchical file system to implement a 'taxonomic' hierarchy of information in my work. Just with the hierarchy, I can find nearly anything I have quickly.
In each file system directory (no, I avoid 'folders'), say, with name x, there is a file x.DOC, yes, in plain text, not from Microsoft's program Word, that indicates the purpose of the directory and documents the files in it.
For a file I downloaded, typically I have the original URL, its title, some of its text, and some of my notes on its relevance to the purpose of the directory.
This DOC file can also record some relevant cross references among files and directories on my hard disks.
So, the top two nodes in my taxonomic hierarchy are PROJECTS and TOPICS. The first is for work that is really just mine, and the second is for information from others. Directory PROJECTS has 59 subdirectories, and TOPICS has 65. Yes, I have some simple command line 'tree walking' scripts I like much better than anything from Microsoft.
Yes, I use text windows and command lines heavily -- again, they are easy for both me and the scripts I write.
(4) Directory Listing.
The scripting language ObjectRexx has a function SysFileTree that will give an 'array' with one array 'component' for each file or directory in a file system subtree along with time and date last changed, length in bytes (modulo 232, for files), the usual file system 'attributes' such as system, hidden, archived, read-only, and directory, and the fully qualified tree name.
I have a simple script that writes this 'array' to a file, typically in the root directory of the file system subtree it describes, with one line for each array 'component'.
The file is in 'fixed fields' and, thus, in KEdit is easily sorted on any of the fields.
And, of course, KEdit has terrific means of 'selecting' lines from the file, and it is easy to write macros, even for just one use, for much more in 'selecting' desired lines.
This file is often very useful for finding things and manipulating files and directories, especially when further processed with macros or scripts.
(4) Facts
I also have a file, and, now, really a small 'system', for ready access to 'facts' or little points someone with a phenomenal memory would just keep in their head.
The 'system' is dirt simple and works GREAT. It's shocking, and even intriguing, how successful such a simple system can be.
Yes, the whole thing is used and maintained using KEdit and with a grand total, please sit down for this, of two (2) macros particular to Facts.
The file is SMALL: It currently is just 812,965 bytes, 26,915 lines, 1,395 separate 'fact' entries, since
Friday, September 2nd, 2005.
That is, 1,958 days, for about
1,395 / 1,958 = 0.71
facts per day.
A typical fact entry is:
==========================
:Created at. 21:18:47 on Tuesday, January 11th, 2011.
:Keys. viral CloudSponge
CloudSponge is supposed to help viral growth.
With promo code TWIVC from Mark Suster, might get freebe for 3 months.
==========================
So, for the problem in the blog post, as I read Hacker News, etc., if I find an article, blog post, fact, etc. that, as in the blog post, I believe might be useful to me, then I put some relevant data on my disk. For an HTML file, typically I will pick an appropriate directory in my taxonomic hierarchy, in a text window use my tree walking scripts to get to the directory, use a KEdit macro to pick a name for the file and put its tree name on the clipboard, have my favorite Web browser get the tree name from the clipboard and save the file as that tree name. Then I have another KEdit macro help me put an entry in the DOC file for that directory describing the file.
So, to find things, a first approach, which usually works, is just to do some tree walking in my taxonomic hierarchy.
If that fails, then using Microsoft's program FINDSTR (a weak version of a good version of the standard Unix program GREP -- there is likely a good version of GREP for Windows, and likely I should get one) is usually enough.
If I am really looking for 'information' on a topic, then, again, the taxonomic hierarchy is a good approach, the DOC files in relevant directories can be better, and my little system Facts can be still better.
Net, the problem in the blog post I believe I have solidly solved: I keep stuff, my own and from the Internet, and can find the stuff either as specific files or starting with just a topic.
As in a kitchen, a few, good, simple tools can be the best approach.
I forgot what the point was already.
It's hard to criticise people's work seriously without hurting their egos.
So, I hope to turn it into a comic one day.