Edit: As pointed out by doakes [1], the project is built by a 13 year old. With that context, I want to preface my original comment by congratulating TheGoodDuck on this project. What follows is criticism, but also do not take it too harshly. These are things I'd expect a developer with experience to know, but not a junior. As you might gather, the issues are even common among seasoned developers. So take the comments as a learning opportunity and remember that criticism of a work is not a criticism of you. These are also soft skills which are often not explicitly taught, but critical to growing as an engineer/developer. If you're doing this at this age and you keep up the work and dedication, you will be a force to reckon with in no time. I am not editing my original comment as this is how I would talk peer to peer and you're a peer ;) But I also wanted to give this context and preface because the style of language is a bit strong. Also note that these issues are very solvable and solving them will make your project even better.
The comments are there to help you improve, not to put you down.
---------------------------------------
You're not alone. Even worse when it is a product page. Just how often I see some product or project and are unable to actually determine what the thing does or why I would want to use it or even HOW to use it.
I can give GitHub projects a pass when someone else links them, but the poster is the author so no pass. This is "Show HN". Please __show__. I do like to try out new projects and tools, but where's the hook?
Also, do not underestimate the importance of documentation. Hell, I document predominantly for myself. I know I'm not alone in forgetting how things work if I haven't touched a project in awhile (which can even be going to lunch on bad days). This is also critical for any users. Encourage them to add docs, make it easy, and when addressing issues recognize that just because it is in the docs does not mean it's interpretable from user context.
If you want to demonstrate a CLI or TUI tool, a common helper is asciinema[0]. You can record your terminal and they'll host the output for you. You'll frequently see these on GitHub and even a 10 second video that is clunky/slow with key presses (or way too fast) is better than nothing. UIs matter and aren't as simple/obvious as many think.
Also, drop a license file in there. Not just a line in your README. Come on, GitHub even hands these files to you so it is the same work to write in your README as it is to drop that file in (though you should always mod those licenses headers to be about you and your project). Without the license file, your license is ambiguous and may not actually protect your project as intended. The full text needs to exist.
No worries, you're all good. Getting the experience to understand expected norms takes time. Just not that often you see such a young developer on the front page of HN, and especially without mention of age in the title.
And just remember: never fear pushing back (even against seniors) and never confuse criticism about your work with an attack on you as a person. I mean all our code is shit. If a year from now you don't look back at your code and think "this is shit" then it probably means you are no longer improving (conversely if you are feeling discouraged and like you're getting nowhere, go back and look at your old code because it makes the improvements rather obvious lol).
Good luck. Keep it up and you'll do great. So don't stress and don't forget to have fun (very common mistake, especially by adults)
Talking about my shit code: https://github.com/thegoodduck/winternet_social Its a social media framework is started builiding maybe 6 months ago now i look at it its just such a mess... I will need to refactor it... It was time when i was working directly on prod server(even on fridays) and occasinally a bug would make the server go down :-)
