Doesn't matter, just choose one that shows potential and do it. The only thing that matters is that you have an end-product in mind that will provide more value to the users than existing alternatives AND that you actually implement it AND the user finds your product.

>If only you knew which one!

That one is actually pretty simple: pick the one that you have the most to learn from, because that's the whole point of doing a side project if you are trying to leverage it as something that would help your knowledge/career development (as opposed to doing a side project for some supplementary income, for example).

And yes, I am aware that there are many unknowns, and when you are trying to pick a project with the goal to learn the most, sometimes the projects where you think you already know 90% of the solution end up being the ones where you know the least and have more for you to learn than projects that had initially more unknowns. But without the ability to know the future, picking the one that has the most "stuff to learn" (according to your first assessment) at the initial discovery phase is imo the most optimal strategy. It is fine if you discover later that the other project had a bit more to learn than the one you picked, because the goal is to learn a lot averaged down over a long period of time.

Which one do you think about when you're in the shower?

Usually there's one project that you just can't get out of your head. If you don't know which it is, try to take a break from all of them, and you'll quickly learn which one maters.

100 side projects isn't "100 ideas worthy of implementation".

100 side projects is the chance at one idea worthy of implementation. If you have even one good idea, all of your bad ideas weren't only worth it, but amount to how you got there.

Think about things around you that could be better. You'll get 100 ideas per day.

Reddit clones can still be novel.

It doesn't take imagination. Rather than trying to imagine the issues, try to develop an eye to see the problems that are already in front of you. And don't start with grand ambitions. Start with the problem in front of you.

One way is to have hobbies, side hustles, volunteer work, whatever. As long as you're doing something that requires solving problems that are different from your day to day programming job, you will find a constant stream of problems that maybe you can improve with a bit of code.

Some of my side projects are directly related to my work, but most of them aren't. I'm working on something right now because someone in my life needed advice on digital security, and it turned out to be not an easy problem to address.

It doesn’t work if you sit down and try to think of something. Inspiration comes spontaneously, you always have to be ready to note any ideas you get. You’ll accumulate ideas over time.

Somewhat relevant, PG has a post on startup ideas http://www.paulgraham.com/startupideas.html

Hmm. What has worked for me is to solve problems I encounter. For instance, I was at a friend's house a couple of months ago and some walkers in the neighborhood shouted that a pipe was burst, and we should report it to the utility company. We called the utility company, and it was difficult to tell them the location of the burst pipe. From there an idea was born, what if we had an app that can report the gps location to the utility company.

The hard part for me is to find the time to implement an idea. An idea for me just naturally flows from a problem.

I personally get 1-2 ideas worth of implementation each day. I always get the idea while doing something and thinking "hey, it would be cool if...". Latest idea I had was when I was playing piano, then played in VR and realized it would be really cool to create a VR trainer/game/vizualizer for the piano to fully immers yourself in the music that you play. So, not only you can be told what to play but you could also shape the entire world/environment around you by what you play. So something like Tetris Effect VR but with you playing the piano instead of Tetris.

Whenever I get an idea, I quickly note the main pointes in a note-taking app and usually never return to it, as the secret of creating actual useful products is to spend the time to create them well. Ideas are worthless if they are not well implemented.

Thursday: I should build an API package for OpenWRT that will track bandwidth usage per device over a calendar period, e.g. past 30 days. wrtbwmon is all very nice, but it simultaneously tries to do too much (offer a UI) and not enough (track data usage for all time). Let me just write that down in my notebook.

Friday: I can build a nice and simple API for OpenWRT that is API focused and provides easier access to the common functions that people want from OpenWRT, this would help mobile app developers create apps that talk to OpenWRT in a simple way. Let me just write that down in my notebook.

Saturday: Let me just sketch out this new design for a workshop cabinet that will let me combine my tablesaw, bandsaw, chop saw and tool storage in a single location.

Sunday: I want my security camera to combine all the detected motion in to a single multilayer video that lets me scrub through events like layers playing simultaneously rather than scrub through time. Let me just write that down.

Monday: OpenWRT should have a "state" that is queryable via a curl request that determines if OpenWRT still needs to be configured. I can build that as a simple API and package it. Let me just write that down in my notebook.

The ideas aren't the problem.

Generally I find that trying to solve problems begets more problems (i.e. side projects beget side projects). Choose a tech stack and start building a Reddit clone, and you'll quickly hit roadblocks and get ideas.

Started a new side-project on the weekend (after a long long hiatus of just focusing on day job). Phase 1 was simply getting the stack up and running (PostgreSQL-backed, Python gRPC service taking gRPC-web through Envoy to a React front-end). Took some fighting through the setup to get a full-stack existence proof, ideas that arose during the working session:

side-project TODO #1 - Write a blog post about getting this all setup using current versions and push a public github repo with the setup to help other out.

side-project idea #2 - Build a micro-PaaS where a customer can define a gRPC interface, Python module implementing that, and with a single command, push this to a live serving endpoint.

side-project idea #3 - I need a state machine as part of my application logic, TODO: write a Python non-ephemeral state machine library that, with a simple Python internal DSL, backs state machine persistence onto a PostgreSQL table, handle automatic schema updates as the state machine is changed / versioned.

Literally not enough time to do any of these things though :)

What's the typical advice here? Something about writing down 100 ideas, diving into detail on your favorite 20, actually build a working prototype for 10 of them, and 2 or 3 will stand out, so pick one of those?

I read that somewhere, possibly here. Maybe someone can link the source, if they have it.

I would choose the one you can't stop thinking about. Or the one that many of the other side projects eventually lead to. If you feel similarly about all 100 side projects, probably none of them are worth doubling down on.

This is the paradox of choice. In most cases, it doesn't pay to spend your time hemming and hawing about find the perfect project. It helps to just pick one, even if it's the stupidest idea of the lot.

The alternative is to wind up as Burdian's Ass, who is equally hungry and thirsty, can't decide whether to eat hay or drink water, and so dies of hunger and thirst.