Many times we get ideas to do something. We get really inspired and start to quickly jot down ideas in code. But what language to use? Probably the language you are most comfortable with will flow write out in the editor, allowing you to see your idea running as quickly as possible.
But what comes next? You now have a proof of concept written in your favorite language, and you probably want feedback on your idea, or you want to start gaining acceptance and momentum for your idea. Now you have to put your code out there in public for the world to see. What will they think about your idea? What will they think about your architecture and code?
These are very stressful questions and a very good point in the process to reflect on your goals for your idea. Are you looking to make this a publicly acceptable standard or library? If so, you're going to be looked to long term to manage growth of the codebase and the acceptance. There may be social norms in your problem-space that trump technical decisions. Are you ready to deal with these things?
Sometimes it's best take a step back and ask yourself, "What are my motivations for solving this problem?" Answers may be:
1) Nobody has done it yet.
2) I have a better solution than an existing solution.
3) Look at me, I did this cool thing!
5) Not sure.
Let's look at each of these in order.
This is usually where you need to ask yourself, "Why hasn't this been done before?" There are usually ethical considerations in the answer to that question. Being the first person to do something bad is not necessarily something you want attached to your name. But let's assume you have no ethical concerns with how your solution will be used, then you should definitely get your prototype peer reviewed. A private repository on GitHub is a good approach with invites to trustworthy people within the community of the problem space of your project is the best first step. Most communities have a public presence on Discord, Gitter, IRC or a mailing list where you can publicly solicit code review and then give invites to the responders. If you are onto something good you'll know quickly and go forward from their with advice from the community.
You will need to put on your Teflon undergarments before making the first post about your project. I cannot stress enough how much you will be challenged to prove you approach is better and how people will not only willingly ignore your facts, but actively attempt to scuttle your work. People's livelihoods are at stake because disruptions to the status quo mean they have to learn new skills (often in a busy schedule where extra-curricular coding isn't easy). It's easier for them to disrupt your project than to disrupt their life.
But if your solution is truly better then don't give up. This is the kind of project that can make a person's career for a long time after the world has moved on beyond your solution because people will recognize the effort it takes to move the bar forward.
These projects are fun, and if you have no expectations for adoption then they can be both good portfolio material as well as the basis for great articles on Medium or DEV that lead to recognition as a good programmer and communicator.
These projects are the ones that change the world, but like with Nobody Has Done It Yet you need to consider the ethics around it. Curious programmers can go deep down some dark rabbit holes before realizing it was a bad idea or counter-productive. Curious programmers also create new industries that nobody knew could exist. But most of all these projects are an expression of your personality and can be an indicator of what you might accomplish as an employee. Publishing these projects can be a great help to your career years after you publish it.
Don't publish anything that you have no clear motivation for! Once you publish something it is out there forever. A disproportionate number of programmers have various mental illnesses ranging from Autism to ADHD to Bipolar Disorder. Projects that have no clear point or goal can be a major red flag to potential employers who would discriminate against people they perceive as a potential problem. Personally, I would rather have a room full of programmers with these disorders as I know that not a single one of them will turn in work that they don't believe in and that they will always put in their best effort.
The projects we create say a lot about us, from the languages we select to our motivations. In the current working environment where FOSS is so important, the projects we contribute to and can be publicly seen are poured over by recruiters and employers looking for the best talent which makes it especially critical that we understand the ramifications of our actions.