I'm a huge fan of side projects. They're an opportunity to exercise creativity however you see fit. They provide you with a chance to work on something where you set 100% of the requirements. They give you a way to learn new skills and new technologies without any time constraints.
For some, side projects exist only to the creator. They aren't built to ship, and they aren't built with the thought that anyone else will ever see or use the project. For others, myself included, one of the best things about working on a side project is the moment it's ready to ship. I enjoy working on side projects and enjoy shipping them just as much.
In thinking about how to approach side projects going forward, I've come to realise that the kind of apps I want to work on as side projects typically aren't going to be fully-featured. At least at first. It's no secret that a considerable amount of my side project time over the last six months has been spent on a weekly podcast. Though it doesn't involve writing code, recording and editing the podcast has been amongst the most enjoyable side project work I've done. The podcast is time-consuming, and I don't necessarily have the time I once did to spend on more polished mobile app side projects - such as with Petty, and HeartMonitor - which were both mostly feature-complete at launch. Petty has received regular updates since its launch, adding features based on user feedback, but at the time it shipped there wasn't a whole lot more I'd hoped to add for 1.0.
There are some side projects I'd like to start working on, but to get them to a point where I'm completely satisfied would take longer than is ideal. As I said, I enjoy shipping side projects. I'm thinking about a different approach going forward. It's not a new or novel concept, but I'm coming around to the idea of shipping the bare minimum and adding to it over time. I guess it's the software MVP approach. I'm not sure if shipping software with limited features will make adding additional features more motivating than if it weren't out in the world yet, but it's something I'd like to try.
The idea of shipping more frequently can be applied to existing projects too. If new iPhones come out, why not release a small update that adds support? That's enough for one update; it doesn't have to wait until a bunch of new features are also ready.
The intention is not to ship poor-quality software, but to have a wider range of public projects, and to ship updates to them more frequently. This might mean v1.0 isn't quite where I'd like it to be, but that's okay. It can then be followed up with fairly continuous updates. Add a small feature one week? Cool, ship it. Fix a tiny bug the next? Ship that too! Updates don't have to be huge. But hopefully, the enjoyment of shipping will still be felt from shipping fairly often.
Software developers are lucky. We can build the software that we want to exist. Going forward, I'm going to try and ship more work more often, even if the project doesn't tick every feature box that I'd like for each release.