One tip I've picked up from experience: avoid projects that have user accounts.<p>If your project has user accounts, you'll get users who you have to take responsibility for. Then it's not a side-project any more, it's a part-time job.<p>These days I much prefer side projects which have no user accounts at all (like <a href="https://www.niche-museums.com/" rel="nofollow">https://www.niche-museums.com/</a>) or that are open source tools where the end user installs and uses the software without me having any involvement at all (like <a href="https://github.com/simonw/shot-scraper" rel="nofollow">https://github.com/simonw/shot-scraper</a>)
Trouble is... I don't think I could build anything that I'd actually have a use for in less than 1-3 months, except for extremely ad hoc things that you can't really predict in advance, like a file convert and rename script.<p>I can think of 4 projects on my own, lifetime total, that I would consider ready for a "Version 1.0.0" tag, and far more that regret ever spending time on, some that required more time on top of that to disentangle myself one(Especially with hardware, where you've now got physical stuff to deal with).<p>The only small projects I've been happy with are the pure toys and decorations. One was a replacement for fortune, but it generates them dynamically using a MadLib style text replacement engine. Another was a candle flicker simulator.<p>Anything tool or infrastructure or library-like has usually become a regret, save for one multiyear megaproject, and a few things with zero reasonable alternatives.<p>I think the best small projects are the ones that are purely self contained, that will never have anything else depend on them, that will never be part of you "personal baggage" to maintain.
For me it works best to start a project in such a way that it is easy to get back to. Fully expecting and embracing getting bored and leaving it gathering dust for a while.<p>For this to work I have docs folder with a todo.txt, architecture.txt, questions.txt and features.txt. I push it early to a private gitlab repo and use a language like TypeScript that makes it easy to come back to and make changes without fear of braking things. It won't be the first time that I get excited (again) by something and can continue on an existing project.
One such simple project for me was <a href="https://kvak.io" rel="nofollow">https://kvak.io</a>. A weekend crafting for a need I had and couldn't find anyone offering - a simple online notepad where I can share the note by just copying the url and the 'sharee' continues writing.<p>The process itself is indeed very fulfilling and joyful.
I’ve created the rcmd app switcher (<a href="https://lowtechguys.com/rcmd" rel="nofollow">https://lowtechguys.com/rcmd</a>) in 2 days, going from statically assigned hotkeys in my BetterTouchTool config to a real menu bar app with dynamically assigned hotkeys for my most used apps.<p>A big part of that time was spent creating the icon, and copy pasting boilerplate code from my other app for the menubar UI.<p>Coding the main functionality of the app took little time and it still remains one of the most fulfilling projects I’ve completed.<p>Of course, I have invested a lot more time since then, especially in handling edge cases with odd keyboards, only because I wanted the app to be useful to as many people as possible.<p>But it could have stayed the way it was as well, where a 2-day project was still solving a problem thousands of people had.
My last projects were controversial. lol. Finished it in 3?ish days. Ruby/Rails/mysql. The elevator pitch: "You place your github project on the site, you rate atleast 5 people's github project, people will view and rate your github project ". It was a fun way to view rando github projects and share feedback.<p>Github security reached out. Banned. All accounts locked. Creepy lawyer emails. Threats. Then i remembered we are in a closed garden now. It isn't 1998.<p>Then I was like oh! I will try another one. What if we allow people to automatically delete comments under 0 points on HN. I had a simple script anyone could run on their laptop. Posting was Flagged. Removed from front page in 10 minutes.
This sounds like it about doing projects <i>for the sake of saying they're completed</i>?<p>My projects tend to be because I want something from them (explore a new toolset; have a working dish disposal; make my car able to play audio from bluetooth; not have to care about network filtering on random wifi aps; get a history of just how bad the temperature difference between rooms at home really is). They're "done" when either I have (enough of) what I want, or I lose interest and decide it doesn't matter that much anyway.
I think it's important to define what it means for you to "finish the project".<p>Is your project "finished", when you see an MVP that you can release to the world? Your project now has a minimum set of features that delivers the initial value you thought it would deliver?<p>Is it worthwhile to do a Show HN on it? (and risk no one clicking on it because HN receives so many submissions? :)<p>Is it worthwhile to release on PH? (and so many products launched in PH thesedays are... pretty much well-polished, revenue ready - if not funded etc)<p>What comes after you "finishing" your projects? Will you continue? or move on to something else?<p>For me, one of the ways to define "finishing" was to make sure that it launches with some type of payment plan. It is an MVP, but it also has monetization in it so that should anyone else wish to pay for it and use it, they can do so immediately.<p>Sure, not all projects are about payment and those projects are fine (which is why I said 'one of the ways'...) but if I know that this is something that I'd like to continue to work on because I enjoy it and I know it has legs, I try to find some way of generating revenue to see what the response would be.<p>Thoughts?
This is great. The fact that there is an incredibly low marginal cost for software projects has been on the front of my mind for a while. Compared to working on something mechanical or electrical, you can get from "fuzzy idea" to "workable-ish code" with incredibly low cost in time and money.<p>I've learned a lot about browsers, for example, chugging away at a little toy website[0] with a buddy. I know it is simple, but it blew me away that I could dig into webkit to see why stuff worked the way it did. We are incredibly lucky to be digging into such an accessible field.<p>[0] <a href="http://legomosaicdesigner.com/" rel="nofollow">http://legomosaicdesigner.com/</a>
I know this will probably not be well received but there are many frameworks that are force multipliers. I see people whip out nice hobby crud sites in a few days with rails. I kind of made one with meteor once though meteor is sadly dead.<p>Another example is Unity and Unreal. Go to any game jam and see how amazingly productive the people are that have learned them and know where all the easy to use assets are as well.<p>Of course the problem with the frameworks (and game engines) is that it's a many month upfront investment to learn them and get comfortable so that when you do want to bang out a new hobby project in a weekend you can.
Last year I participated in the advent of code challenges. I remember a puzzle from day 16 [1], which took an afternoon or more .<p>The idea is really great, however it seems quite hard to solve interesting problems in this short timeframe.<p>[1]: <a href="https://adventofcode.com/2021/day/16" rel="nofollow">https://adventofcode.com/2021/day/16</a>
Great read.<p>I think this is a good place to reference Tiny Projects [0], which to me are a manifestation of what is described here.<p>[0] <a href="https://tinyprojects.dev/" rel="nofollow">https://tinyprojects.dev/</a>
I can barely finish a leetcode hard in a few hours, let alone something I would call a project. Still, this is an inspiring approach to tackling day to day work in incremental micro-projects.
For me, the best small side projects involve some kind of porting (between protocols, OSs or CPUs), contribution of a fix for a visible but mysterious bug, or revival of codebases in bad shape, especially when they're unfamiliar and written by others. You can learn a lot from a software engineering culture that's different from yours or small, feasible projects that allow you to understand the bits and bytes of something unfamiliar in a fun and useful way. These projects are great to develop flexibility and general problem solving intuition. And getting familiar with the 20% of an idea, a protocol, a programming language, etc' that's used 80% of the time in real-world use cases, is often enough.<p><a href="https://github.com/dimkr/gplaces" rel="nofollow">https://github.com/dimkr/gplaces</a> (Gopher -> Gemini port)<p><a href="https://github.com/dimkr/paho.mqtt.embedded-c" rel="nofollow">https://github.com/dimkr/paho.mqtt.embedded-c</a> (revival of an abandoned library, WebSocket+TLS+Windows+Meson porting sub-projects)<p><a href="https://github.com/dimkr/loksh" rel="nofollow">https://github.com/dimkr/loksh</a> (OpenBSD -> Linux)<p><a href="https://github.com/dimkr/locwm" rel="nofollow">https://github.com/dimkr/locwm</a> (OpenBSD -> Linux)<p><a href="https://github.com/puppylinux-woof-CE/woof-CE/projects/1" rel="nofollow">https://github.com/puppylinux-woof-CE/woof-CE/projects/1</a> (a bunch of GTK+ 2/X11/X.Org -> GTK+ 3/Wayland/wlroots porting sub-projects)<p><a href="https://github.com/dimkr/gtk" rel="nofollow">https://github.com/dimkr/gtk</a> (x86_64/ARM64 port of a 90's library)
I like the ethos behind this post; I've been struggling to finish projects for years, I get desmotivated, jump into another thing, don't finish it, come back after months now lost again, advance a little bit, drop it after a weekend, repeat, etc.<p>I will try to use the framework presented here but I'm not sure exactly how to apply it, for example the project I've been meaning to finish is what I call a very dumb compiler (parse a very simple language and emit x86_64 assembly code but without any optimizations, the most naive thing that will work).<p>It's hard to think how to reduce this problem to something I could do over a weekend; I have to do a lot of research, thinking and trial and error because I'm not an expert in writing parsers or anything like that.<p>I feel like this might only work in certain occasions.
I was between clients for a few weeks and I wrote some apps for practicing musical scale patterns in different keys, and something to automate voice leading from chord to chord. Best three or four weeks in the last few years.
I shipped my 'smallest' side project last week[1]. It was someone DM'ing me on Twitter trying to engage with my half-finished website that encouraged me to spend most of my weekend getting it to MVP.<p>It is annoying to ship something that isn't as polished as I want it to be (order fulfilment is a bit janky). But this annoyance is certainly outweighed by the joy of actually delivering something. The polish can come later is a decent amount of people start engaging with the digital project.<p>1. <a href="https://ddiaflashcards.com/" rel="nofollow">https://ddiaflashcards.com/</a>
Probably works for a certain class of projects, but not for many.<p>For example just recently Zas editor[0] was on HN whose developer spent >1 year building it. How do you restrict that to a weekend?<p>Similarly the creator of bun.sh[1] (Javascript build+runtime) has been working 80 hour weeks on it for 6+ months.<p>Ambitious projects like those _will_ take time.<p>[0] <a href="https://news.ycombinator.com/item?id=30952084" rel="nofollow">https://news.ycombinator.com/item?id=30952084</a>
[1] <a href="https://bun.sh/" rel="nofollow">https://bun.sh/</a>
Meh... someone of us like the depth that comes from longer-term projects.<p>Don't get me wrong, I've taken art classes that taught me to appreciate smaller, shorter things. And I think it's important to take that spirit into longer-term projects. But I think there's just a lot more "small" projects these days, what with the combination of APIs, funding, hackathon culture in engineering, and prototype culture in design. The pendulum has gone all the way to the end. Which is fine too, but some of us are going to want to go the other way.
Ok, maybe. Examples would help, though. Specifically: describing the process that goes from the big dream to the smallest implementation feasible in an afternoon.
Short projects are an excellent way to learn a new tool or framework. Want to learn Next.js? Looking for an excuse to try that new Golang game engine? Pick an obscenely small goal and you'll likely have more fun exploring the docs and learning the tool than getting stuck in the weeds of the myriad requirements not helping you learn that new tool.
This is delightful and well-stated. I don't think a timeline is necessary, but I do think a sense of urgency "get the prototype done as cleanly and quickly as possible" is helpful. Create an exhibition of the smallest novel component. And there you have it, progress.
A small project [1] that I use often on projects and teaching is a text-based ERD editor. Being text-based means I can write it with minimal tooling (with vim or vscode) and in git-friendly format. Since the students (and myself) requested more functions, I keep enhancing it occupationally but it is already useful since day-1 :)<p>I think the key motivation is being able to see the actual users (ideally also being the active user yousrelf)<p><a href="https://erd.surge.sh/" rel="nofollow">https://erd.surge.sh/</a>
I've worked on simple projects, but nothing I would consider small in the sense that I had them done in a matter of hours. But it is satisfying having a project come together in terms of completion, even more so when you reap the benefits of its use. The one that comes to mind for me would be the static site generator I built for my site, something I spent some time working on as I continued to use it, and tweak it for my needs.
I agree with this and I haven't done enough of these kind of projects but I did create this parkrun map as the one on the parkrun website was not very good.<p><a href="https://www.moreofless.co.uk/map-of-parkrun-5k-running-events" rel="nofollow">https://www.moreofless.co.uk/map-of-parkrun-5k-running-event...</a><p>It's really simple but I use it often myself and other people are finding it too, which is nice.
>Make your projects small and finish them every time.<p>The only part I would disagree with. It's also important to know when to kill a project that's not going anywhere, where finishing won't provide any value. Yes, finish <i>almost</i> all your projects, but there are those few that are not worth reluctantly dragging out (especially if you've now found another tool that does the job).
I do small projects all the time. Most are modules for integration into larger ones, but I develop and publish them as standalone projects. In fact, I’m working on one right now. I’ll probably publish it tomorrow.
One of my more useful tiny projects was simple command line search until for the windows registry. It helped a lot back when I was making installers and apps that used the registry a lot.