So, I was all set to start writing some unit tests to begin the refactoring I described below.

But then I needed to do a bit of procrastination, first. 🙂

That article is good advice for procrastinators. But what grabbed me was this :

You can accomplish a lot more in small increments — even fifteen minutes is enough time to do a little bit of quality work. Just get a decent start, and don’t worry so much about finishing. If you start often enough, the end will take care of itself.

That’s the ideal for the smart disorganized individual. Working in a lot of 15 minute (or shorter) fragments according to your inspiration, energy and available time.

But there’s a big problem : switching costs. Every time you drop something and pick it up later, you have to re-aquaint yourself with the context of what you were doing. You have to recharge the short-term memory. Of course, if you’d documented what you were up-to initially, returning would be easier. But in fifteen minute bursts, who has time to write documentation too?

Without that, a lot of your fifteen minutes, and a lot of your energy, get wasted on rediscovering what you were doing previously. Or even, if you’ve totally forgotten (as I sometimes have), redoing something that was already done! That makes the SDI way less effective than someone who can actually concentrate and stick at one task for a reasonable length of time.

Not surprisingly, I think personal wiki is the beginnings of a solution. What’s needed is somewhere to keep track of what you’re doing as simply as possible. And while you are doing it.

Notes should be written to accompany the process. Ideally, you can open a notebook, create a new page and just get down to it in less than a minute. Using the notebook as a scratch-pad for your ideas while you work.

Then, when you want to switch out of that context, You want to hit “save” and be finished with it. Not hit “save” and be having to think : “where shall I put this document in the file-system? Oh, God! Is it better to put it under ‘My Documents/teaching/advanced-programming/examples/’ or better to put it under ‘Development/Python/adPro/’ Wow! I’m such a loser because I can’t keep my files sorted”

Similarly, when you return to the project, to make the most of those 10 – 15 minutes, you want to recover that context quickly, not frantic scrabbling around hard-to-click little folder-icons in Windows Explorer, waiting for the turgid “Find files or folders”.

You usually remember enough about the project to remember its name. So you really just want to type that name into a convenient place on the screen and be there.

Alternatively, stick a link to each project, slap bang on the start-up page of the notebook in large letters. In a personal wiki this is trivial. You just hit edit; type the page-name link; save; go to the page. Now the context is reachable within one click of opening the wiki.

If you have several projects on the go, put a bullet list of links to them as the first thing on your front page. That puts them all easily within reach. When the project finishes or becomes less of a priority, you can move the link elsewhere : further down the page or onto another one.

On the other hand, maybe when you started thinking about “BirthdayInvites” yesterday, you forgot to link this from the front-page. It’s not really a big project, but today it would be nice to get there quickly. But what did you call it? In this situation, the RecentChanges button is invaluable. Hit “Recent” and yesterday’s (and the day before’s, and the … etc.) edits are within one-click.

In exceptional circumstances you forgot the name of the page; you last touched it months ago; and you don’t remember a route to it from the front-page. Now “search” comes into its own. If you can remember just a name or word that’s likely to be in the page, you can search for it. It’s a little longer, but it will still get you there faster than wandering cluelessly in Windows Explorer.

Why is wiki so good for this? Well, having built-in search and RecentChanges is handy. But hypertext, not hierarchy means that a wiki can have “small world” properties. Everywhere is only a few clicks from everywhere else. Compare this to what happens once your file-system gets crowded and in getting from the Ping project to the Pong project you might find yourself going up five or six levels to find a common root of the two, and then navigating (more or less blindly) down another branch of the file-system. Going down is less comfortable than going up. You have to scroll around to find the right icon to click in the absurdly cramped “file open” dialog. That’s assuming you recognise which route to take at all. Often you find yourself guessing wrong, going down the wrong sub-branch, and having to backtrack.

Join the Conversation

1 Comment

  1. Phil, a local Wiki is certainly a good idea, and as you say – a start.

    But it has an inherent flaw, as in HTML – links. On the surface a link works, but it’s linked the wrong way – it should have been linked from the source! If you change the file or its URL or place in the hierarchy then the link is broken…

    Tags are better that way, or “ln -s” in any nix system 🙂

Leave a comment