I came across an interesting article in my feed this morning that resonated quite strongly, and not in a good way - If you don’t finish your work then you’re just busy, not productive. Turns out I've been incredibly busy.
I've recently taken a new position that involves relocating to Thailand - any relocation requires you to prioritise all your physical things and relocating to another country just magnifies that effect. As part of the packing, prioritising and sorting process I discovered that I don't really finish things and that was a very dissapointing realisation to come to.
Oh, there is a lot of stuff that is working - I have sensors all over the place, an infrastructure to collect and store that data and a range of other services and tools I've built but all of it feels transient and incomplete. Everything is just a placeholder for the next version which will be better in some unspecified way.
... I frequently find myself starting new programming projects in my spare time. In a lot of ways they are not a waste — I definitely learn a lot from these projects and gain a new skill. Yet at the same time, because I move on to something else that interests me before I can finish ...
Software projects are the worst - reading that section of the article made me feel a lot of empathy for the author because that is exactly how I feel now. As he says, you learn a lot (and in fact my new job entirely involves technologies I learned how to use in side projects) but without a completed working project to show at the end it's not as fulfilling as it could be.
Hardware projects tend to fare better, at least in my case. Part of this is that a hardware design is more formal (you need a circuit diagram, a PCB layout, gerbers to send for fabrication) and design changes are far less fungible than in a software project (want to swap out an AVR for an ARM chip? That's a new PCB design and you probably need to review the power supply as well). My hardware projects tend to have far better documentation and design notes and I have a deeper understanding of what they are and are not capable of.
I won't be able to run self hosted servers for a while (they will be on a slow boat from Australia) so I started migrating a lot of things to public (or at least cloud based) hosting instead - this process gave me a good overview of all the projects (complete and incomplete) that I have. So far I've found:
- Over 300 Git repositories - these range from full projects to casual experiments.
- Nearly 30 draft posts for the blog (and a lot of pages in my Wiki tagged article)
- Over 40 pages tagged idea in my Wiki.
Even if I don't start anything new there are several years worth of work involved just to finish everything off. Clearly this isn't going to happen. I am going to have to be a bit harsher about discarding projects that are no longer relevant, will take too long or just aren't as important as alternatives.
Another important thing to do is to define what finished actually means. In a commercial environment this is relatively easy to define - a product on the shelves or a new version available for download. For personal projects, that often start as an open ended idea, it's not so easy. I am hoping that by putting some constraints on projects I can break them into manageable milestones that represent some sort of completion state - that way even if I don't progress any further with the project it is at least in a well documented state which achieved some pre-defined goals for utility. In other words - not just interesting, but useful.
Some constraints I'm considering applying include:
- Time - I've found that I can spend about a month on a project before I'm distracted by something else. That sounds bad, but it's true; the distraction can often be directly related to the project as well - a new CPU or a new software framework becomes available and it's tempting to start over with the new technology.
- Documentation - it sounds a bit formal for home projects but I've found it to be very important. I'm not talking about a full blown requirements specification here but at least a blog post about the project on completion and a Wiki page of design notes during development would make it a lot easier to come back to later.
- Publication - each project must have at least one blog post about it and it should be started at the same time as the project. Part of this is the joy of sharing what I enjoy with others and adding to the blog content but another important part is that describing something for a third party helps you focus on what you are actually trying to achieve.
The way things stand I am not going to be able to do any electronics development for a few months (I am not looking forward to that) and even pure software development is going to be severely constrained until my servers and desktop arrive. On the positive side this gives me the opportunity to decide what projects I want to work on when I can (rebuilding my sensor network in Thailand for example) and which ones can be discarded. I should also be able to catch up on my writing and finally end the six month drought on the site.