This library is clearly not written for the authors own personal benefit. Just look at the old readme; it's obviously written for other people to use and play with.
Examples and screenshots are good; there's no reason for anyone to be defensive about not having them; the author can just add them. It's no big deal; it's helpful feedback.
>> People on HN have a very bad habit of assuming that any time something appears on HN, it's because the authors wanted to put on a show for HN. No.
> Oh please, what kind of excuse is that?
Just demonstrated tptacek's point. The author could be at a point where he wants others to see, but isn't quite ready for places like HN yet. In that case, it's not an excuse. Attitudes like this encourage pathological perfectionism.
You don't need to polish something into a shiny gem of perfection before showing it to people; and you certainly don't need to get defensive about feedback (which in this case wasn't harsh at all); especially not for something out in the public that various people are already using.
Iterative feedback and improvement can only happen if you get feedback.
It's tempting to say that something isn't quite ready for others to see yet, it needs a bit more polish, and bit more internal beta testing, a bit more perfecting before you show it people.
...but I'd say that most cases, it's not the right attitude to encourage (although there are some very specific cases; like product launches where a botched launch has long term negative ramifications).
Have a think about what you wrote there.
You're endorsing self defensive attitude of perfectionism that you're criticizing.
You're endorsing self defensive attitude of perfectionism that you're criticizing.
No. I'm endorsing thinking a few steps ahead when criticizing. I think that should be the lower bar for feedback. Otherwise, it's too easy to engage in "feedback" as a means of self aggrandizement while humiliating others, which is as close as we can get to the Internet's official sport. (In particular, knee-jerk statements can be used to win over an uninformed crowd. They are the favorite ammunition of trolls.)
You think that perhaps danudey needed to stop for a moment and have a quiet think about that before posting it?
Yes, and he should produce a tree of possibilities and if he doesn't have evidence precluding them all, he should briefly hypothesize about the most likely positive possibility while making his request for further information.
Another way to interpret this: He should think like a creator as opposed to a consumer. I think it's fair to ask this of visitors to GitHub, as it's fundamentally a site facilitating the process of creation.
We all need to do more reflection before writing, myself very much included. Unfortunately, the reward structure of the Internet combined with human nature seems to encourage the opposite.
Partially true; I was driven to write this because I wasn't particularly satisfied with what already existed for various differing reasons. The current feature set and my own short-term plans are based around the GUI projects that I intend to write first (specifically a music authoring program).
As for screenshots, I suppose I could upload a screenshot of the test program, but I'm not sure how much that would accomplish. I think a basic tutorial with screenshots at each step would probably be more useful, as it shows how the package works...
This library is clearly not written for the authors own personal benefit. Just look at the old readme; it's obviously written for other people to use and play with.
Examples and screenshots are good; there's no reason for anyone to be defensive about not having them; the author can just add them. It's no big deal; it's helpful feedback.