Live data from Hacker News

Name It, and They Will Come

overreacted.io

21–30 of 116 posts

Re: Name It, and They Will Come

#22
And what happens when you tell the story and everybody just completely ignores you?

TBH I find that a lot more frustrating than ppl missing the point on what you were trying to say. That is exactly is what happened to me a week ago... I will keep on trying, though :-)

Re: Name It, and They Will Come

#23
post #15
post #6

I honestly don't understand what this post is trying to say. Most of it just describes the usual internet bike-shedding ( https://en.wikipedia.org/wiki/Law_of_triviality#Examples ), and then says that you could have avoided it by just... telling a story or naming something, but doesn't elaborate at all on what it means by that, how to do it, or why it would help.

> I honestly don't understand what this post is trying to say. It says that most users wont try hard enough to understand a post, and instead comment like people are doing in this thread. (It also suggests to try and give name to what you've built, and and try and weave it into an explicit narrative, to help people understand it and give more focused responses).

Okay, but what does that mean in practice? Almost every project posted on HN already has a name and at least a short description of why it exists or what it's trying to do (often in the title itself). They still get bikeshedded to hell, so obviously the name and story alone aren't enough. I see a ton of posts where people bicker specifically about the name or the story (half the comments are "is this actually an issue?").

The linked post spends the entire time describing the problem but only 4 tiny sentences on the solution. It's really not self-explanatory even though it treats it like it is. Was writing it this way intended to be some kind of meta-commentary that's just going over my head?

Re: Name It, and They Will Come

#24
As a researcher you will notice that simple and catchy title for your paper will give you far more citations than a paper that has more descriptive titles.

If you are publishing a paper about new way to optimize a problem, just give it a fancy name first.

Re: Name It, and They Will Come

#25
post #23
post #15

Earlier quoted context omitted.

> I honestly don't understand what this post is trying to say. It says that most users wont try hard enough to understand a post, and instead comment like people are doing in this thread. (It also suggests to try and give name to what you've built, and and try and weave it into an explicit narrative, to help people understand it and give more focused responses).

Okay, but what does that mean in practice? Almost every project posted on HN already has a name and at least a short description of why it exists or what it's trying to do (often in the title itself). They still get bikeshedded to hell, so obviously the name and story alone aren't enough. I see a ton of posts where people bicker specifically about the name or the story (half the comments are "is this actually an issu…

I honestly think part of this is just Dan's writing style in general. When I read his posts I often get a sense of him wanting to try and explain ideas at a conceptual level and teach people how to think and apply the concepts themselves, rather than provide step by step instructions for anything. I am far from an avid Overreacted reader though, I just read what gets posted here, mostly.

Re: Name It, and They Will Come

#26
This kind of thing is very frustrating for creators.

It’d be cool if comments could be sorted based on their relevance to the article, post, project, or idea as a default, rather than just by time or popularity.

Re: Name It, and They Will Come

#27
post #23
post #15

Earlier quoted context omitted.

> I honestly don't understand what this post is trying to say. It says that most users wont try hard enough to understand a post, and instead comment like people are doing in this thread. (It also suggests to try and give name to what you've built, and and try and weave it into an explicit narrative, to help people understand it and give more focused responses).

Okay, but what does that mean in practice? Almost every project posted on HN already has a name and at least a short description of why it exists or what it's trying to do (often in the title itself). They still get bikeshedded to hell, so obviously the name and story alone aren't enough. I see a ton of posts where people bicker specifically about the name or the story (half the comments are "is this actually an issu…

I wish Dan (the OP) had gone into more detail on exactly what techniques one can use to tell a story, because this is exactly what he does - very well! - as one of the most prolific voices in the React (and perhaps all of frontend) community.

My personal take:

(1) Marketing shouldn't be an afterthought; it must be considered in the same way one would write code. Take a page from the folks who designed a custom website and icon for Heartbleed. To put it another way, think of "things that would distract someone from the main message" as "bugs" in your code. Certainly, some bugs need to be triaged before any launch. But they should all be triaged with open eyes and respect for the user experience.

(2) Don't assume people know acronyms or even the basics of your niche. Talk about potential use cases. Walk someone through the naive way of doing things, a less naive way of doing things, and why your thing naturally evolves/iterates on those. Make separate "background" pages if you want. Then take all of that as you would an essay you're writing for a class, and reshape it - find a thesis statement, tie everything back to it. Your launch post/README is a persuasive essay on why your thing is good. Even the "getting started" details are part of that persuasion - if it's easy to use, that's part of what makes it good.

Well-written technical documentation can be a joy when you are immersed in the excitement of the person who built it. And with any immersive experience, there are things that can take you out of it. Immerse people quickly and keep them there, and maybe, just maybe, they'll be curious enough to do background research on their own and engage with you on the merits of the project with context :)

Re: Name It, and They Will Come

#28
post #6

I honestly don't understand what this post is trying to say. Most of it just describes the usual internet bike-shedding ( https://en.wikipedia.org/wiki/Law_of_triviality#Examples ), and then says that you could have avoided it by just... telling a story or naming something, but doesn't elaborate at all on what it means by that, how to do it, or why it would help.

I think that the article itself is a pretty good example of its own point. The bike shedding phenomenon is not new but it's hard to relate to it in the particular form described by the article. So the article describes that form as - a story.

Besides, I find that there's often/sometimes a big gap between understanding a concept (like bike shedding) on an abstract level compared to being able to relate and to it when it arises in practice (unless perhaps you've grasped in some special way). Telling various stories that exemplify such concept in a multitude of ways can reveal new facets of it.

Re: Name It, and They Will Come

#29
post #11

That sort of minimalist looking webpage using a big round font for the headers really does make it hard to absorb the gist of the post - sorry, have I overreacted? Perhaps a less fleeting writing style could have set up a more concrete thesis that would deliver a conclusion to their statement. That last bit is actually quite relevant - due to law of triviality and such there will always be bikeshedding, but the way t…

I love the meta-ness of this comment. Not sure if it was intentional :-) One concrete example of naming a problem is “callback hell”. Example of “telling a story” to explain it: https://tirania.org/blog/archive/2013/Aug-15.html Once you have a few articles like this, the quality of discussions on the topic rapidly goes up. For React, David Nolen’s and James Long’s early posts did the same thing.

It was, to my knowledge there isn't a great way to flag that sort of thing on the web (short of * WINK *)... I thought the fact that I apologized for having "overreacted" when discussing the blog post hosted on overreacted.io would be a bit of a give away.

That callback hell story differs from the one above in that I think it delivers a much better summary statement at the end and way forward - I have some opinions on it's aim as I think it is eschewing power in terms of a more comfortable expression for imperative programmers - but the article is well sized, clear, humorous and suggests a solid remediation for the perceived problem.

Re: Name It, and They Will Come

#30
post #5

My problem with open sourcing my code is I always feel like someone else must have done it already and done it better. On the subject of irrelevant comments: I see HN more as a place to discuss topics relating to the OP link rather than discussing the OP link itself. A lot of the value of HN for me comes from learning how other people see a subject or what related ideas/libraries there are. For me as a commenter, the…

About the 'someone else must have done it better already' if I can't find it then others might have not been able to do that either, that is where my solution could help. And even if not then just having a alternative implementation from which others can learn is pretty neat.
Post reply on HN