Notes From The Dork Web

How I Approach Projects

Over at 82mhz.net Andreas wrote an insightful post I read this morning about his unfinished projects. Having just finished a project myself, I thought I'd write about how I've recently changed the way I've approached my projects.

I'm normally terrible for not finishing projects. I have so much junk from unfinished and half-finished, even unstarted projects it's not even funny. Right now on my desk I can see my unused Palm Pilot VX, A USB Floppy drive with a still-packed Greaseweazle next to it, various minidiscs I meant to take downstairs and put in a storage box, my G4 Mac Mini that needs some work on it and an OS rebuild, and that's just what's in front of me.

I decided to do the Windows 3.11 Zine only after starting this year's OCC. I originally didn't plan to finish it, but as I was already partway through migrating my OpenWRT Wifi bridge into a home server (I started in March) I thought I'd take a different approach to both projects. Previously I would've gone at each project for a while before finding somewhere to put it, never to return. For both projects I decided I'd change tack.

I'd previously made a folder in Obsidian for the OpenWRT Server project and even wrote some documentation, but decided later to focus on getting the job done. I wrote a quick note defining what constitutes as "done" for the project and chipped away at it until I was happy with it. Along the way I decided to remove some goals because they weren't really that important to me.

For the zine I made an Obsidian folder for the project, wrote down all possible zine ideas and decided to do the Windows 3.11 first. I then started working on it and chipping away until I was done. Instead of focusing on a destination, I try to carve out time and dedicate the time to making progress. This doesn't always work out as I tend to pack too much in. I usually end up moving the needle and persistence eventually pays off.

I'm also now much more aware of my available time. For example, I currently write Mondays off entirely as I'm teaching at a local school for a few weeks and helping with the School's IT. There is no point in allocating anything for a Monday. It's just not going to happen.

So to conclude, what works for me best is:

  1. Write a description of the project and all possible ideas to get it out of my head.
  2. Pare back to what's achievable, with no specific timeframe.
  3. Maintain a batting order of projects as they reach the achieved state.
  4. Work on one project at a time with the option to temporarily jump to another if the first is getting too painful.
  5. Allocate specific times each week to work on these projects and only (and exclusively) work on them in these times.
  6. Be prepared to cut items from the projects if they're not really needed and be prepared to accept good rather than perfect - I can always refine in a later iteration (e.g. another Zine, an OpenWRT upgrade etc).
  7. If a project fails completely which sometimes happens, fail fast, do a quick personal post mortem and move on.

Looking at Andreas' list he has some really cool projects. On my personal tech project list I have:

Each of these will get a note as I get round to them. I'm probably doing the CF-U1 next, but might have a go at the Wifi card this weekend. It's worth noting that the list above is unfinished (and in some cases unstarted) projects.

I have a non-tech list too. I'm just not as good at maintaining it.

#meta #uses