I'm with Marco Arment on this:

Boring old is the key to server-administration happiness. Stick to the boring and the old, and you’ll rarely need to deal with anything.

He recently spoke about this on atp, too.

The general idea here is: Old boring software tends to run a lot better. He's talking about server code, but the general notion is an interesting one to consider when it comes to personal productivity.

Of course, there is a spectrum here. Taken to an extreme, I shouldn't use VS Code but Emacs or VI(M), for example. But what would be even worse is to change text editors every few months - I see this, the constant change of apps for a specific use case - as one of the biggest problems in trying to build a reliable setup for knowledge work.

In most cases all of us have certain apps already in place for certain use cases. The idea here is to keep using the app and asking yourself if whatever is missing, is actually missing and then think about a change you actually would like to introduce to the current productivity system as a refactoring.

As an example for sticking with what you have, let's consider the case of missing automatic backlinking functionality in Evernote. This feature is not provided by the app. We can link notes manually though and this is actually good enough in most cases. It has the additional benefit of making me engage with my notes more. I don't need to change to ikiwiki (for example) just so I have automatic backlinking functionality.

It is a hard lesson to learn that sticking with something is almost always more beneficial than changing things up, I found. I have only learned it myself through a long line of disappointments, triggered by changing apps and my setup fairly quickly and on a whim at times. Sometimes it worked out, but most times it did not.

I nowadays think that platform agnosticism can be used wrongly to facilitate easy changes to your setup instead of ensuring longevity of data. Using plaintext just so I can bounce around between iA Writer, nvAlt, Sublimetext, etc. pp. is not a way to happiness.

Instead, I want to suggest to stick with what you have and only in special cases consider a change. If you are indeed moving things around, do a proper analysis, what you will gain and what you will lose. Reorganising things from an old system into a new system just for the sake of it is not valuable work. Tidying up and refactoring an old system, on the other hand, is.

I therefore suggest that, if you really need to change any pieces of your setup to consider things like scriptability and automatisation facilities, since this will enable you to stick with the software you are already using. This is why I like things like Evernote for my notes or DevonThink for my Documents and OmniFocus for my Tasks. Learning how to use Applescript and Keyboardmaestro really helps to relieve the need to change software all the time.

Of course, it's not always a straight-forward thing. We're all human. I have chosen Evernote as my notes system on a whim and got lucky. I just recently switched to DevonThink and am in the process to move documents over to it. But all of this is a slow process. An app change or addition as is the case of DevonThink is a sort of refactor of my current document management.

Whereas a change like the one to Evernote should not be seen as a good example (although I was in the middle of moving to a different country and needed an app I could use reliably on my phone, which TiddlyWiki simply wasn't), picking up DevonThink might be considered an okay move.

Maybe the Pareto Dominance Principle could help:

The Pareto Dominance Principle (PDP) requires that, when changing the functionality of your product, you can never accept even a small degradation for any (reasonable) user.

The only user of your productivity system is probably you. So ask yourself: Are things only getting better, when changing a piece of my setup or in the worst case stay (mostly) the same? If the answer is no, then don't change systems.

If following this principle, a ratcheting effect will be felt: the setup will be much less in flux and will only get better.

Marco Arment suggests to run mostly boring server side code and software. It's easier, probably more reliable and predictable. I suggest to mostly make do with what you already use and might find boring by now. You already know how to use it and therefore it will be more predictable to you. You know its upsides and downsides. This is a good thing! A setup should only be as good as to enable meaningful work and otherwise be resilient and only get better.

If you find yourself struggling with the software you already use: Change one thing at a time. Use the Pareto Dominance Principle to slow you down somewhat and consider the benefits but also the cost of changing your system.

Another Macro to help working productively with a Zettelkasten in Evernote. This was inspired by a forum user on zettelkasten.de.

This one copies the contents of a linked note into the note which holds the link under the line in which the note link appears. I had to work around some limitations of the Evernote Applescript Library, which doesn't allow to edit a note programmatically (you can only append text). Therefore this relies heavily on the UI-scripting capabilities of Keyboard Maestro.

If anyone has ideas on how to improve this script to be less fragile (since UI-scsirpting is a fragile thing…) I'd be happy to hear them! :)

Prerequisits

• Keyboard Maestro

Setup

1. Download the macro (see below)
2. Import the Macros to Keyboard Maestro
3. Configure a hot key trigger for the macro (I have it set to 'ctrl'+'alt'+'shift'+'cmd'+'L')
4. Move the cursor within a green note link, press the hot key
5. The macro runs on my mac in about 1.5 seconds, be sure to let it do its thing before doing anything (using your keyboard, changing windows, etc.)

How it looks

Download

Just download the file and drop it onto the Keyboard Maestro App Icon in the dock, or double click the file.

Evernote Note Expansion (application/octet-stream, 11 KB)

I recently took part in a discussion about using a Zettelkasten as an aid for programming and was asked to elaborate on my comments there.

A note on maturity

The current incarnation of my Zettelkasten is only a few months old and far from incorporates my old Zettels fully, yet. I know that with the maturity of any notes system or its infrastructure it "reveals" its actual form or maybe rather develops in a certain way, sometimes against one's own intentions and/or expectations - in other words: the system has agency. With that said, I have been using a Zettelkasten approach for many years now and am fairly confident, that the following remarks are not just guesses on what works for me and my Zettelkasten - your milage still may vary, of course. However, I still found it to be necessary to put a disclaimer here.

What I need from a Zettelkasten when coding

I recently had reasons to examine my usage of my Zettelkasten as it pertains to developing. I realised that there are patterns observable on when I stop programming and looking up information.

• I need to know how to do something
• I need to know how a specific thing is implemented in the given framework, programming language, etc.
• I need to know the definition of a pattern, concept, etc.

The process

When looking for information, I am somewhat time constrained - my job is to write code, good code that follows best practices, sure, but still: it's not research or writing the most comprehensive private documentation on how to write code and its underlying principles. Therefore the character of my searches is as follows:

1. Search your own Zettelkasten for what you're looking for. If the information is found and there are no important loose ends: Great! Stope here. Code on.
2. Try to acquire information until my interest has been satisfied, I am able to continue with the task at hand or my time is up (I am interrupted, I am supposed to do something else, etc.)
3. While and/or after the research phase is over, I try to note down the new information. The idea here is to make my current temporary understanding available later, by putting what is in my short-term memory into my Zettelkasten

You will note that process is not that different from working with other materials: You read with interest, take note and move on.

Considerations

Groupings - Abstract, concrete, How To's

I found it helpful to differentiate between three different groupings of notes:

1. abstract concepts - ideas, definitions, patterns, etc.
2. concrete implementations - APIs, documentation of functions and keywords, classes, etc.
3. HowTo's, concrete solutions and approaches

These categories mirror my needs (see above) when wearing the hat of a programmer. They also make clear that there is a difference between the concept (e. g. the data structure array) and its implementation (arrays in PHP and Javascript are very different).

Highlight what you're talking about

So in order to keep things separated (depending on the categories, see above) I make sure to make this visible in my note. Right now I use Backticks around the implementation. Here's an example:

Exceptions of Type Error are thrown for the error types E_ERROR and E_RECOVERABLE_ERROR

Note length and composability

I try to keep my notes short and composable. As for other Notes as well, the principle of atomicity holds true. A note should do one thing. Of course, what constitutes "doing one thing" is only roughly specified. But regardless, the goal should be composability. I find that as a developer I benefit from an already highly structured standard of documentation in my field, which can be a heuristic for my Zettels on the topic.

For example, I have created these Zettels when trying to understand the difference between an Exception and an Error in PHP:

1. PHP - Error Handling (Links to: 6, ...)
2. PHP - Throwable (Links to: 1, 3, 4, 5)
3. PHP - Exceptions (Links to: 1, 2, 4, 5)
4. PHP - Errors (...)
5. PHP - Difference Error vs. Exception
6. ... and some others

This approach works for more applied things, too. For example for various Git tasks, I have a bunch of notes that basically just hold the line to enter into the shell and maybe a link to a related command and to a "parent" or outline note. The important part here is that I try to build trees of notes.

Since the actual coding is done outside of the Zettelkasten, notes from this part of the note system tend to be much more conventional in style, meaning they mostly hold information, but aren't necessarily emergent in the same way as conventional knowledge notes might be (the more removed from the implementation the notes are the more they behave similarly, though). It's simply not helpful to abstract too much from a concrete code snippet to enhance composability, though.

But when talking about software architecture the drafting of how a system could look like is very similar to other knowledge work.

Tagging and Linking

I do not really handle tagging and linking differently from other parts of my system. Nonetheless, these are things I try to do:

For linking notes together or linking a freshly created note to already existing ones, I'm looking for a local fit. This means: Whatever the overall structure of my note system might be, the incoming and outgoing links are the context in which the note has meaning. E. g. if I'm talking about an Exception in PHP I might define it as opposed to a PHP Error and as a specific case of Throwable.

For tagging, my main target is a semantic anchor, wich means: Whatever the note is content-wise, it relates semantically (it articulates) to this tag (because I say so). So for example the Throwable note is tagged as PHP (or rather 00-meta.01-setup.04-dev.03-languages.01-php but I digress…). The note articulates an aspect of the PHP language and relates to it on this level. Looked at from the other side the meaning of this note comes from it being related to the PHP language which is expressed through this tag. The tag anchors and associates my notes in a different, probably more broad, way. There could be more tags. But I find that being economic about the tags I use is more beneficial.

Both linking and tagging are two different techniques to enhance the meaningfulness and emergent properties of the note. I'll probably talk about this more some other time.

Example - PHP - Error Handling

Because an example says more than a thousand words, here are some screenshots of some of the notes I have referred to above, warts and all. These are young notes that will get better with time. But even in this state they already helped me to differentiate quickly between two different kinds of Throwables PHP gives me. I apologise in advance, for my notes are in German:

20200324102302 - PHP - Errors

20200324102529 - PHP - Exceptions

20200324104152 - PHP - Unterschied Error vs. Exception

SCM - Git - Wie man ein Branch erstellt und dann gleich hinwechselt