That wasn’t the point of my reply. By “see a need, fill a need” I wasn’t suggesting coming up with arbitrary needs like that article suggests. I was saying that actually finding a need that has a demand is what drives most of my projects.
Take for example my old Vanilla BuyCraft project. There was a real need, and demand, for this type of project at the time of me making it, hence why I made it.
More recently, CemUI was conceived when I saw members of the Cemu community complaining about the Cemu UI, and wanting the developers to make it cleaner. Thus that project was born, and RiiU is built partly from the demand in the Cemu community to allow online play without a WiiU, and peoples concerns over the WiiU’s EOL.
Please don’t misinterpret what I mean by “See a need, fill a need”, as it isn’t what you are suggesting.
I finding that seeing what people actually have a demand for, and building applications around those demands, to be very beneficial as it builds real-world application development experience and pushes you to have actual clean and function code (which is an important practice) as opposed to spaghetti code found in most random/practice projects (I am very guilty of this myself. CemUI 1.0 was 100% spaghetti code), among the other generic benefits of practice-projects such as keeping skills sharp and learning new things.