Bookmarks have been around since the earliest browsers. With years I’ve accumulated thousands of them, and I’ve heard of similar numbers from other people. As it grows, it becomes obvious some organization is needed.

The organization scheme that comes naturally, at first, is folders. Those have been there since the early beginnings with Adam and Eve when the Web was young and domain names were aplenty in the tree of TLDs. That’s what I relied on for about six thousand years, and it became a huge mess. I still have old folders from my antique “classification system” I never look at anymore except for quick-and-easy nostalgia.

Tags and multiple axis for classification

So it quickly becomes obvious more axis are needed to classify. The most self-evident case is when doing a project: you’ll quickly accumulate a bunch of links which are contextually related because of the project, but otherwise would end up in different categories.

For example, if you’re creating a web site on video games, you accumulate links on, say, Nintendo, HTML, marketing and Ramen noodles, but in the Grand Scheme of Things (ie. Dewey classification, or some directory like dmoz.org), these are not usually put together.

So you end up trying to set up some keyword/tag system, hack together for 20 hours some frail Firefox extension, and then Firefox 3 comes along and does it for you anyway. The end result is you can create a tag for your project, yet also tag with proper general categories.

With a personal wiki

But in my experience that still doesn’t work, based on the fact that I never look at the bookmarks again, except when I have a very precise idea of what I’m looking for. And then there’s Google anyway.

In fact, currently, I only use local bookmarks for

1. Transition until I put them in my wiki;
2. pages and sites I use all the time, so I need quick access (online tools etc.).

Why is it that my old bookmarks were still condemned to live unfullfillingly in the dark for eons? There are many reasons, but the main one, for me, was that bookmarks don’t offer any formatting options and their context is not rich enough, even with tags or folders.

When you write a blog post or wiki entry, you can use context, explanations, and the links make sense. They’re part of the text, and when you look back at the entry, you don’t just see a list of equally-created bookmarks, but each has its place and the content you summarize, the description you make create a whole, and of course it’s text so you can have sections, bullet points, images and whatnot.

So my current system is one where I put my bookmarks in wiki entries related to their topic, with some summary explaining why it’s there and what I extracted from it, if I read it. If I need more axis, I’ve developed a WikidPad extension to tag a part of a page.

It seems to work: I reuse the links much more often, and it actually creates value for me as the content slowly grows with the links and knowledge instead of just being an anonymous bunch of pointers.

Of course it requires a bit more work for each link, but in the end if you’re not willing to spend 30 seconds writing a quick note, perhaps it wasn’t worth bookmarking anyway.

(This post is geared towards programmers.)

This blog is about structuring your personal knowledge. Code snippets and, more generally, programming language information, are interesting in that everyone and their cubicle neighbor seem to have their own approach to organizing them. Here I survey some interesting software and approaches I’ve read about, their features, and present my own method based on my personal wiki.

This post is an example where wiki features come in handy (by opp. to a thorough survey of Code Snippet Management as, err, an academic field of study).

Software and approaches

A code snippet manager is a piece of software which allows you to organize short pieces of code to reuse later. Yet I’m also seeking the ability to integrate general information about the language (explanations, elements of theory, etc.): in my experience, snippets are often examples of a notion I’m learning.

In researching a bit on existing systems, I’ve found a few feature families:

• Code features
  • Syntax highlighting
  • Management of multiple files (a plus if you want to add entire libs to your snippet database)
  • More specific:
    • automatic indentation on insertion
    • dependency management
    • IDE integration
    • (other noteworthy?)
• Organization and retrieval features
  • Hierarchical: by language, by functionality/algorithm
  • Tags
    • Tags are particularly useful here (vs pure hierarchical) because I’ll often stumble on situations like:
      • I need a snippet in whatever language for a quick sort algorithm.
      • I need a C++ snippet with an iterator loop.
  • Full-text/regular expression search
    • Regular expressions are especially useful since you often seek specific constructs and regular text indexing won’t cut it.
  • Hyperlinks (well, hallmark of wikis here)
  • Date and other general fields
• Sharing

There are lots of different approaches and systems. Specialized software exists that allows you to organize your snippet library in a standalone and dedicated manner. Google Snippely is an example:

Screenshot of Google Snippely

A whole bunch of sharewares exist that do similar jobs. Some IDEs come with a snippet manager integrated, as is the case with Visual Studio. Most of these local programs offer a basic outline for organization with more or less search capabilities. If you’re looking for an online version with tagging, check out Snipplr, which, being online, also allows you to share and search others’ submissions.

Snipplr homepage screenshot

In the homebrew solution department, this thread is interesting. Some people talk of filesystem based solutions. A few even use a custom database. Personal wikis (as I use, see bellow) and general outliner software clearly need mention too. For example, this blogger says she uses Microsoft OneNote to organize her snippets.

Getting a bit less personal, it should be noted a quite a few bloggers describe their blog as being a “repository for them to search later”. Therefore blogs and websites somehow count as personal snippet libraries (I did a bit of this with my old me-me-me blog over yonder). These score high on integrating other information (ie. free-form formatted text) with the snippets, and of course on the sharing aspect. Community wikis (ie. not personal) are also a great way to organize and share snippets and knowledge (examples here, here).

As a side note, it’s pretty clear we won’t only rely on our own snippets when coding. “The Web + Google” describes my most often used “system” when searching for coding solutions. Yet there are specialized search engines for this job: Google Code Search (you can use regexps on the whole DB!), Koders, and quite a few more.

My approach

Given earlier posts, this doesn’t need a drum roll introduction: I use my personal wiki to organize my snippets and my programming language learning. Of course, this solution allows for inclusion of formatted text. I admit I have a strong tendency to use my snippets for learning more than for reuse, so that factor might weight more than usual in my choice.

A wiki will allow for many different types of retrieval. For example, using the right combination of plugins, with WikidPad I have hierarchical organization, tags/keywords, full text and regular expression search, and, of course, linking. Most popular wiki systems will have plugins to allow for syntax highlighting, and WikidPad is no exception.

Code snippet screenshot in WikidPad
(using the PrettyCode extension)

Where that solution might be lacking is in the IDE integration department, and in the management of multiple files. In the last case, I have a separate personal code (file system) directory to which I may refer using file:// links.

Digression on repetition

Information overload has numerous causes, and one of them is plain old repetition, e.g.: two sources delivering the same information, with superficial differences. It’s natural to repeat information for various reasons.

As an example, when students take notes on a teacher’s lecture, they all duplicate basically the same information. If they all decide to put their notes online, bam, 30 new versions of “Notes on Heisenberg uncertainty principle”. Same goes for journals and bloggers reporting on a given event.

Of course there might be additional value to each version, different points being made, but for someone doing research on recent events, he still gets to read again and again the same basic facts.

Clearly there’s no simple solution. In fact I might mention here that discussion in the blogosphere does create repetition, but makes that information evolve. Something similar happens for students exchanging notes. In this light, repetition appears as a necessary evil.

If we really want to get philosophical, let’s just say repetition is unavoidable from the very start, as production of repetitive information is just the consequence of information flowing in the social graph and of different human beings going through similar experiences and train of thoughts. And clearly it’s not because one of them has eaten apple pie that humanity can move on and experience other stuff.

Gratuitous picture of humanity’s bane (source)

(Ah, of course, the irony here is that this very article is just some remix of ideas told a zillion times over).

My WikidPad extension

Yet, being aware of the problem, you can at least work on making your own set of notes as repetition-free as possible. That’s another core reason why I love personal wikis. Instead of rewriting information on two pages, as you’d do in paper notes because you don’t have your old notebooks handy, you simply link to the other page and voilà! you just avoided adding a little more repetition to this world (why not add some grandiose here? ).

Yet there are cases where where linking is not enough. Say I’m taking notes on the differences between two programming languages, C# and Java. I have a page on C#, a page on Java. Where do I put the notes? I could create a page dedicated to that topic, but I don’t have enough material for the moment to justify that. So say I put them in the page about Java. Consequence: when on C# page I have to navigate to the other page to read the info.

Diagram explaining the extension

What my extension does is grab the info on the Java page (and any other page) and dynamically bring the relevant sections in the C# page. Technically, you give the extension a keyword, and it will search your whole wiki to find pages that contain it. Then, in those pages, it searches for precisely the lines that contain your keyword and some context around it (”sections”). It then prints a list of those sections.

Now it doesn’t matter as much where I put the notes. As long as I label the sections correctly, I can centralize them in the relevant pages when needed, and I don’t need manual copy anymore.

Grab the code & read details here: http://www.fsavard.com/flow/wikidpad-dynamic-search-results/

In my introductory post on personal wikis, I briefly explained their use to organize personal knowledge. I also said I use WikidPad, personally. Here’s the rationale behind my choice.

Main points

WikidPad is a desktop application, so you have to install it locally, as opposed to wikis accessed through the Web. It works on Windows, Linux and Mac OS X. You can download it here, and here’s a quick start guide.

The killer point, for me, is that WikidPad allows for quick edition and navigation. Speed is crucial: if you feel slowed down, chances are you’ll just give up or at least won’t use it with all benefits of a personal wiki.

WikidPad screenshot

Wikidpad main features are:

• Easy and quick edition of entries, with on-the-fly formatting and linking (explained bellow)
• Outline view (on the left) and other navigation helpers (ex: history of last accessed entries, useful keyboard shortcuts)
• More ways to structure your entries
  • TODO lists produced by gathering TODOs on all entries
  • Entries attributes, which allow you to list all entries that have a given attribute
• It’s open source, written in Python and can be extended with modules
• The data is stored in plain text, one .wiki file per entry

The “programmer’s point of view” in the title stems from the fact that the speed of edition might be achieved with more conventional edition behavior (WYSIWYG or Word’s style edition), but then one loses the wiki syntax which to a programmer (or simply nerd) is very appealing for being similar to plain text formats. That’s the unique mix of WikidPad, from what I gather.

Edition behavior: details

WikidPad has a sort of dual-mode of edition/viewing. An example is best to explain: if you mark a word be in *bold* (with asterisks), you don’t have to switch back to “formatted view” mode for it to be showed in bold: it’s shown that way while editing, on-the-fly.

Example of on-the-fly formatting
(++ is for title, *for bold*, _for italics_, etc.)

That turns out to be a real time saver, for me. With all other wiki software I have used, edition is done differently, in either of two ways.

In one case, there’s a constant switching back-and-forth between “formatted view” and “edit view”. TiddlyWiki operates in this way, for example. The thing is, most of the activity done in a wiki involves small modifications here and there, so this “switch” happens often enough to make it cumbersome, to my experience.

In the other case, the WYSIWYG (What You See Is What You Get) behavior, you don’t have to switch, but you format using buttons or keyboard shortcuts, just like in Word (ie. you select the text and click “B” to make it bold). Most people will probably find this a better option, but as a programmer (or just a nerd?), I love the fact that there’s nothing hidden: what I write is all there is in the .wiki file that represents the entry (ie. you work directly at “source” level).

Side note: programmers will recognize WikidPad’s behavior as being the one of an IDE (integrated development environment), esp. for the code coloring aspect. That’s why WikidPad motto is “an IDE for your thoughts”. It also features auto-completion of WikiWords, as another similarity.

Outline view

Example outline (here for the help, which is itself a wiki)

A killer principle of wikis (vs traditional note organizers/outliners) is their very flexible structure: you’re not restricted to having a note be a “child” of one and only one note. You can link from any entry to any other. Yet hierarchies are very intuitive, since we’re used to placing files in folders, and folders in other folders, etc.

WikidPad gives you both. Sure, you can link from any entry to any other one. But an entry linking to another one automatically becomes a “parent” in the hierarchy (outline) displayed to the left. And yes: an entry may have multiple parents that way. (Surprisingly, this does not cause any universe-shattering paradoxes)

This outline gives you yet another way to navigate in the wiki and speed things up.

Extensibility

WikidPad is open source and written in Python, a language which many programmers like to work with for personal projects. WikidPad allows you to write and load your own extensions.

Some extensions you can readily use allow you to visualize the topology of your wiki (with GraphViz) or include mathematical formulas or graphs (MimeTex, Ploticus).

Links and references

• WikidPad home page
• “First start” quick guide for WikidPad
• Someone doing medical research and using WikidPad to take notes (mentioned in other post)

One of the tools I want to explore further here is the personal wiki. It has played a central role in my knowledge workflow in the previous years, and helps me getting my thoughts and learning in order.

Concretely, the tool I use is WikidPad, which has many interesting features, but I’ll get back to it in other posts, for sure! But if you want to get started amazingly quickly with nothing to install, just take a look at TiddlyWiki: it’s a single Web page you save on your computer and you got an instant personal Wiki.

Wikis and personal wikis

Wikipedia is probably the best known wiki system. A wiki is an hypertext, meaning, like the Web, that it’s a set of pages linked together by words that point to other pages, ie. hyperlinks. Another feature of a wiki is the simplicity of page creation: a simple syntax that looks pretty natural, making it easy to create lists, sections and links. You can learn the basics in under 10 minutes.

One last feature I’ll mention is the collaboration aspect: usually, a whole group (or everyone) can edit a wiki. Basically, you create a page, add some text with the wiki formatting, save it, and it becomes a Web page. Then, someone else comes on that page, clicks the Edit button, makes some changes, clicks Save, and the Web page is modified.

Editing a WikiPedia entry

That’s where a personal wiki differs: only you modify it. It’s up to you to decide whether to share it or not, but other viewers can’t modify pages.

Advantage as a note taking tool

The way I propose it here, you use that wiki as a note taking tool, but a pretty powerful one. You can link entries to one another. You can link to Web pages or documents. Over the months, it can become rather huge. It’s your own space: you organize it as you see fit. The links give structure to the whole, and you use them to navigate from a page to another.

You can use it for whatever note taking you have to do, and all your notes exist in the same “space”. This allows you to link an entry on (say) avocados to recipes, or notions of gardening or Mexican geography, if you feel like it. Now, whenever you learn something new about avocados and write it on that page, that notion is “near” those other pages, due to the links you can click on to quickly access that related information.

As a further and more concrete example of a personal wiki in action, take a look at this post by a medical professional who uses WikidPad to organize some of his professional knowledge.

As a project management tool

Some people will also use their personal wiki to organize their projects. Once again appears the power of linking to whatever you want: your projects involve specific topics (say, creating Web pages), and you can easily link to those topics from the pages concerning the project. Then, when working on the project, you’ve got all this related information a mouse-click away.

As an example in action, there is a version of TiddlyWiki that is specifically made for the extremely popular Getting Things Done (GTD) personal organization system: GTDTiddlyWiki.

Screenshot of GTDTiddlyWiki

A mirror of your own knowledge

A clear consequence of being the only one modifying your wiki is that, well, all modifications were done by you… If you use it consistently, that means your personal wiki becomes a mirror of what you know.

While learning, you may enrich it. As some do in school by note taking, you reorganize the notions you grab here and there on a given topic, make them your own by reorganizing them along the way you chose to divide the topics, and adding personal experience you had with knowledge you really used. You can also eliminate the parts that are less interesting or seem to overlap each other.

There are a wealth of benefits, in my own experience, but the sense of truly building something while learning is my personal favorite. You’re not plainly reading, you’re truly building your knowledge and have something to show for it.

In the following posts, I’ll be sharing some elements of my experience with a personal wiki. I know I’m definitely not alone in that practice, so if you have you own experience here (weird use cases etc.), you’re very welcome to comment!

Related posts

• Personal wiki: WikidPad, from a programmer’s point of view

Further links

• Impressive list of personal Wiki software
• An introduction to the Wiki concept