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.