Even if you don't understand the point the author is trying to make, this part you should be able to understand perfectly, and I find it a perfectly accurate description of what happens 90% of the time:
= = = =
The top comment thread picks on the coding style in a README example. It turns into an argument about indentation with over a hundred replies and a brief history of how different programming languages approached formatting. There are obligatory mentions of gofmt and Python. Have you tried Prettier?
Somebody mentions that open source projects shouldn’t have beautiful landing pages because it’s misleading marketing. What if a junior developer falls for it without fully understanding the fundamentals?
In a response, somebody argues the landing page design is boring. Additionally, it’s broken in Firefox. Clearly, this means the project author doesn’t care about the open web. Is the web as we know it dying? It’s time for some game theory…
The next comment is a generic observation about the nature of abstractions, and how they can lead to too much “boilerplate” (or, alternatively, “magic”). The top reply explains that one shouldn’t confuse “simple” with “easy”. Actually, Rich Hickey gave a very good talk about this. Have you watched it?
Finally, why do we need libraries at all? Some languages do well with a built-in standard library. Is npm a mistake? The leftpad accident could happen again. Should we build npm right into the browser? What about the standards?
The internet has always had more noise than signal. HN used to have an incredibly good noise reduction mechanism, mostly thanks to self-policing in the community and the occasional intervention of the moderators.
Thanks to this mechanism, most of the time, the top comments were really interesting ones. The noise usually ended towards the bottom of the page.
I'm pretty sure that the expectation that this would happen made people - often busy people - spend time to write very thoughtful comments, which could then raise to the top. A positive, self reinforcing loop. Which is getting slowly, but surely, less effective with the years.
I wish there was a simple formula to reproduce the original mechanism. But I'm afraid there is not.
There once was a model railway enthusiast. He loved trains and knew just about everything about them. He had a wonderful collection of model trains. One day he met someone with the same love of model railways. Together they built complex simulations and had their trains running together. They wrote software that could schedule the trains, etc, etc. A few more people noticed and while most people said, "Wow. These guys are the real geeks" a few said, "Wow. These guys are amazing" and joined the group. Eventually there was a small club of highly dedicated model railway enthusiasts who knew practically everything about model railways.
One day there was a person who like model railways, but wasn't really that into it. However, he noticed the model railway club and realised right away that these people are amazing. He would go to the meetings just to bask in the glory of the incredible things that these people built. Eventually, he couldn't keep it to himself. He told a whole bunch of his friends and they all showed up too.
The model train club started to get bigger and the original members couldn't be happier. When they first started most people looked down their noses at them. Now they were downright popular. One day some of the members said, "This really amazing stuff is really amazing, but I wonder if there is a way for me to approach this without being quite so geeky. I have a family and I don't have so much time. I want my train setup to be super awesome, but I don't really care that much about the details".
Lots of the other members were in the same boat and so they worked hard to have a kind of "scaled down" setup that would appeal to people who didn't have the time or energy to devote themselves completely to model railways. The club became even more popular due to this and lots of people who really liked trains, but weren't that interested in model railways started to show up.
Eventually several of the members started to have outings to visit train museums and to have photo competitions on train themes. To raise money they even made a calendar with pictures of trains. The model side of the club was a little bit less accessible to most of the membership because the core group of enthusiasts were interested in highly technical details that most other members were not interested in.
Eventually, it was decided that the model railway club should change it's name and purpose in order to be more accessible and welcoming to new members. It would now be the train enthusiasts club. Of course model train enthusiasts would have a place, but it would be appreciated if they refrained from having heated discussions about highly technical and inaccessible topics like programming train simulations and the like.
Eventually, the original model railway enthusiast stopped going to the club. He liked the people. They were great and friendly, but he was, after all a model railway enthusiast.
If you take something that appeals to 1% of the population and scale it to include 20% of the population, it morphs into a thing that the 20% group likes, not the 1% group. Can't be helped. It's just a matter of numbers. It happens everywhere.
This is a fantastic way of describing the CS "culture" of my school. So many people who like talking about tech without ever bothering to learn the actual underlying skills. And yet they're nominally CS majors...
Thank you for presenting such a vivid example. Something that appeals to a minority, will, by definition, stop appealing to them when it morphs into a form that appeals to the majority. I have seen this happen even with TV series. Is there a name for this phenomenon? I do agree with the article where it says "we can’t discuss what we never named"
It could be tied to Leopold Kohr's observations https://en.wikipedia.org/wiki/Leopold_Kohr#Philosophy
and to the way our typical political party hacks his platform in order to gain votes. In some ways 'quantity kills quality'.
I guess one way to handle this is to subdivide the field so there is a hierarchical structure and you can zoom into subfields to capture the the heterogeneous interests of a large body people?
A related example is where a town is a great place to live because of lots of walkable attractions (grocery stores, YMCA, parks, a variety of little shops, cheap rent for other small businesses, theaters, music halls, etc.). Then lots of people want to live there, driving up prices. The stores, non-profits, small businesses, etc. all get bought out and replaced by expensive housing. And then one day people who have lived there for decades realize that the town is not that great place to live anymore because there is nothing interesting to walk to there, no jobs, rents and taxes are high, and grocery shopping involves a long drive...
It can take some active planning and foresight to avoid that. Related:
http://shirky.com/writings/group_enemy.html " I want to talk this morning about social software ...there's a surprise. I want to talk about a pattern I've seen over and over again in social software that supports large and long-lived groups. And that pattern is the pattern described in the title of this talk: "A Group Is Its Own Worst Enemy." ... So these are human patterns that have shown up on the Internet, not because of the software, but because it's being used by humans. Bion has identified this possibility of groups sandbagging their sophisticated goals with these basic urges. And what he finally came to, in analyzing this tension, is that group structure is necessary. Robert's Rules of Order are necessary. Constitutions are necessary. Norms, rituals, laws, the whole list of ways that we say, out of the universe of possible behaviors, we're going to draw a relatively small circle around the acceptable ones. He said the group structure is necessary to defend the group from itself. Group structure exists to keep a group on target, on track, on message, on charter, whatever. To keep a group focused on its own sophisticated goals and to keep a group from sliding into these basic patterns. Group structure defends the group from the action of its own members."
http://www.t0.or.at/delanda/meshwork.htm
"But even if we managed to promote not only heterogeneity, but diversity articulated into a meshwork, that still would not be a perfect solution. After all, meshworks grow by drift and they may drift to places where we do not want to go. The goal-directedness of hierarchies is the kind of property that we may desire to keep at least for certain institutions. Hence, demonizing centralization and glorifying decentralization as the solution to all our problems would be wrong. An open and experimental attitude towards the question of different hybrids and mixtures is what the complexity of reality itself seems to call for."
Part of the challenge is that human mentality evolved in the context of hunter-gatherer tribal relationships -- growing up in a tribe of mostly related kinfolk you knew from birth. It's a huge stretch to expect the human mind (and its ability to manage social relationships) to functional well in other contexts... Frankly, it's amazing the human mind works in other settings as well as it does.
I feel like there was a real step-change when dang introduced a policy of requiring comments to be more positive (and I think implying people hadn't read the article was banned at the same time)? If you look at old HN comment threads you'll see a lot more caustic replies to wrong/stupid comments, and while superficially cruel I really think that was what kept the quality ratio high.
Yes, I understand the rationale behind that decision, but I've been chastised a couple of times for comparing the tone of comments to those on Reddit. Which didn't look to me as offensive :)
How good would software and ml have to be before you wouldn't really need to have centralized forums? If the content of messages could be sufficiently indexed automatically- not in the sense of keyword searches but in the vein of actual comprehension- surely there are ways of doing that without anything that far from what currently exists. I don't think it would require skynet.
As someone who has only ever succeeded in bringing down the level of every discussion i have ever been in and never in contributing anything useful, it would be very helpful if i could just be automatically directed to the appropriate content sewer by posting my thoughts directly into a search engine that could dump them in the most suitable location.
The point is that, for many years, there was a well shared understanding of what was signal and what was noise on HN - even if there were hot disagreements on the content of that signal. This is changing.
> I wish there was a simple formula to reproduce the original mechanism. But I'm afraid there is not.
I've been toying with this idea. My go to would be to do a pagerank on the vote graph. The intrinsic quality of a webpage was transitive enough to make Google win the search engine war; surely people can be viewed as websites that have links indicating quality to other commenters: HN accounts and votes to someone else's comments.
If only HN could release the vote/down dataset...
That could be a privacy violation. Maybe they could do it themselves, or try to disclose it to select trustworthy parties.
Maybe they're doing it internally and they're keeping it to themselves. After all, YC is in the business of detecting precisely individuals that are capable of articulating high quality ideas.
You could (relatively) easily, implement Pagerank but use votes instead of links. This would make people who have lots of (quality) upvotes have more weight.
Whether it would improve the quality of the comment sections is an interesting question. I'd be interested to see that tested somewhere ...
This quoted section on its own makes it sound like Dan is complaining about all the people who aren't discussing the thing he (the creator of the tool/library/idea) wanted them too. I thought the same thing as I first read this section. But I think it becomes clear that he's not making that complaint, or at the very least, he describes a clear reason why people tend to discuss certain concepts, and offers a way to try to get your concepts discussed.
I disagree, I think the article was very lacking when it came to actually offering concrete advice to address the situation or, at least, was very obtuse in the giving.
To have a focused discussion on Thing X, ask for a focused discussion. The scenario he stated (discussions on the README getting picked up and whitespace preferences being spun into a mini-holy war) is just... it's going to happen unfortunately. But that discussion wasn't one the author initiated for feedback, it was a general comment thread on the repository. If you, as an author, want to spark an intelligent discussion on your product than do just that, present the points you want to debate while allowing some freedom for that noise since it isn't always useless.
Instead of: "Hey HN, I just wrote a badass new streaming protocol" and linking to the github source, specifically mention your concerns about continuing to rely on TCP for video streaming and the buffering lag it induces, link to a blog-ish thing which links to your source but frames a number of questions or doubts you have around your project if you, indeed, are at a loss and want to turn to the internet as a whole to try and solve them.
Basically, as I do in my workplace, refuse to let your discussion/meeting/whatever become a vaguely directed waste of time - set a clear agenda (i.e. a set of specific points in a blog post) to help funnel the discussion toward the useful parts. In the resulting chatter you'll probably get some whitespace criticism (spaces are simply poor manners, #tabs4lyfe) you'll get some chatter about your question (and on HN that'll be floated to the top) and you might get someone who dug behind your question and found that - yea TCP is bad, but if you're going to use UDP you'll need to have some solid check-summing in place which your project currently lacks.
So, you need to direct the discussion, but allow noise, without noise you'll eventually settle the discussion into a local maximum of functionality where everyone is nodding and saying "Yup we did it, it's not a solvable problem but we've clearly come up with the best partial solution."
I actually think your suggestions are perfectly compatible with a charitable interpretation of this article.
> Instead of: "Hey HN, I just wrote a badass new streaming protocol" and linking to the github source, specifically mention your concerns about continuing to rely on TCP for video streaming and the buffering lag it induces, link to a blog-ish thing which links to your source but frames a number of questions or doubts you have around your project if you, indeed, are at a loss and want to turn to the internet as a whole to try and solve them.
That sounds exactly like an example of Dan's suggestion to "tell a story."
But my suggestions actually offered a story indicating what was wrong in a (hopefully it was sort of off the cuff) clear manner. I found the article to be lacking a clear demonstration of what was wrong and specifically actually lacking a clear solution.
What I stated above wasn't what I read in the article, it was my proposed solution to what I discerned the issue to be.
People chatting about random topics prompted by the link is the whole point of a link aggregation discussion site. The discussion is not intended to precisely meet the needs of the person who created or submitted the link, and it’s silly to dismiss it because it predictably doesn’t.
If someone wants e.g. concrete technical feedback about a new specialized tool that takes hundreds of hours of preparation to appreciate, they should find a forum consisting exclusively of people with enough background to give meaningful feedback, and then describe exactly what kind of feedback they are looking for.
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?
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 :)
> To put it another way, think of "things that would distract someone from the main message" as "bugs" in your code.
This is the PR/communications industry. Once I understood this, and that a main message is one sentence at most -- a short phrase is even better -- interviews of people in politics made a lot more sense!
Yep, the same way we write code and think “what are the implications of this function were called from a weird context,” so too do PR/communications folks “engineer” statements.
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.
As an example, see the "Middleware" tutorial page in the Redux docs [0], which Dan wrote. It walks through the process of "how and why did we end up at the final middleware API?", by demonstrating several "failed" attempts at solving the problem of logging.
The page itself is well-written, and definitely demonstrates Dan's standard teaching style. But, it's also true that it's not obvious from glancing at the page how to _use_ middleware, because that doesn't come until the "failed" attempts.
Another good example is his "Redux tutorial" videos on Egghead [1], where he walks through basically building Redux as the process for teaching how to use it and how it works.
For some people, that teaching style is great. For others, they just want to know _how_ to use something, not necessarily how it _works_ right now.
(We're planning to revamp the Redux docs soon-ish [2], and I do plan to change the contents of that "Middleware" tutorial to be an actual explanation of how to _use_ middleware correctly, and then move the "why does it work this way?" explanation to a different section of the docs.)
"If you, as an author, want to spark an intelligent discussion on your product than do just that, present the points you want to debate while allowing some freedom for that noise since it isn't always useless.
Instead of: "Hey HN, I just wrote a badass new streaming protocol" and linking to the github source, specifically mention your concerns about continuing to rely on TCP for video streaming and the buffering lag it induces, link to a blog-ish thing which links to your source but frames a number of questions or doubts you have around your project if you, indeed, are at a loss and want to turn to the internet as a whole to try and solve them."
Dan doesn't say this, and I don't want to put words in his mouth, but the point I take away from this isn't that people are lazy and don't want to dive deep on a new idea, but instead that people are not obligated to discuss and give you exactly the type of feedback you want.
Even if your idea makes it to the top of HN, people are completely free to discuss ancillary topics or give feedback on areas you aren't interested in (like the coding style or design of the blog post).
And Dan proposes a solution. The solution isn't to decry the low quality of online discourse, or call people lazy, or use moderators to force people onto specific topics. The solution is to tell a story that people are interested in.
Telling a story is the only solution that works. You either tell your story, over and over and over again until you can't stand to hear it, or you disappear into the noise. You pound the story home, or your competition will and they'll take up that mind share. There are many ways to tell and disseminate a story, that's the primary variable in successful products, not whether there's a story at all.
I believe part of the point is that we often go beyond bike-shedding to off-topic bike-shedding. Something written in X language turns into a discussion of whether X is a good language. An announcement from company Y becomes a discussion of everything else Y has ever done. It's a website and has a design, so let's discuss web design.
On-topic bike-shedding would actually be an improvement.
I believe this happens most often with announcements that are legitimate news but kind of boring. The larger, generic topic is more interesting and it's sorta related, so it's more attractive to talk about that.
A possible solution: be more interesting. Tell a story.
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.
He’s telling a story describing our situation that is hard to directly talk about. David Foster Wallace once said in an interview [1]:
> Let me insert one thing, which I'll bet you've noticed from talking to writers—is that most of the stuff that we think we're writing about in books is very difficult to talk about straight out. You know, question and answer. In some sense, it probably can't be talked about directly, and that's why people make up stories about it.
You tell a story in which you show the problem and the solution besides. There is no other way to create interest. It has to solve a problem of yours (a potential problem may be enough). If you don't know it does, why would you care about the solution?
Or that's my interpretation of the article anyway.
One way to avoid the pitfall of folks resorting to talk abt 'universally shared experiences' is to take control of the conversation: One way to do that is to offer AMA, or ask a question yourself.
I've seen the keybase founders (esp malgorithms) and to an extent the Cloudflare founders (esp jgrahamc) do it pretty successfully here.
For clarity... I wasn't a founder of Cloudflare, but I was an early employee.
I try to answer questions about Cloudflare, or comments about the company, here when I have the time. I do the same on Twitter (and to a certain extent on Reddit). I have code that monitors HN for mentions of "Cloudflare" and emails me within a couple of minutes.
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 to cut through that (in my opinion) is to clearly set a scenario, set an agenda, open with a problem and set the dialog up to resolve the problem. This is why I have begun (usually) refusing any meetings without a clearly outlined agenda, and when agendaless meetings get an agenda sometimes I'll duck out of the meeting and submit feedback in writing _to_ the agenda. This is also why I have a bit of an issue with this article, it is titled in such an irrelevant manner that it can't help but generate bikeshedding around it - the title is good and catchy sure, but I really don't understand how it relates to the actual meat of the article (which does raise some relevant points).
If the suggestion is that naming (adding a short descriptor) to... "stuff" makes it easier to keep discussions about that stuff on topic then please back it up with an example, provide some justification, instead the article reaches ~95% then doing a hard right to inject a catchy quote that seems unrelated to the rest of the verbiage.
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.
> 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?
I agree, but fortunately for us the people who adopt this weird presentation format almost universally write in a very specific style. I find it easier to just read the headers (or, if they're really bad writers, the headers plus the sentences they felt necessary to typeset in bold), since that's usually the whole message. The rest is some kind of weird boilerplate, like the narrative version of lorem ipsum.
If there were more consistency in HTML tag usage I'd write a browser extension to throw everything away except the useful text, but we haven't reached that design mecca yet.
I'm trying to figure out what both you and the grandparent poster are getting at. Usually on HN we're criticizing people for having too much crap on their pages, hard to decipher designs, tiny text, and what not.. not that their pages are clean and minimalist. What's "weird" about a clean page that's mostly text?
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 threads I like are exactly the ones that a submitter might not like: threads filled with many semi-related comments.
I do think we absolutely have a problem with overly negative and discouraging comments on HN (and the programming community in general) though. The worst kinds of comments are comments like the “yet another js framework...” on someone’s show HN. You’re discouraging someone’s work on their specific library by bringing up some larger problem you see in the industry. So I absolutely agree that those sorts of semi-related comments belong in a separate post on that specific issue.
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.
> My problem with open sourcing my code is I always feel like someone else must have done it already and done it better.
Why does your thing have to be the best? There’s nothing wrong with your think existing; who knows, it might actually be the best or end up becoming the best someday.
We tend to discuss things that are easy to talk about.
AJAX (as it was at the time) is a prime example of what Dan's talking about, I think. As a term that enveloped the whole idea of having JavaScript dynamically load content from a server, it really brought developers together in discussing and experimenting, and even resulted in naming a publication on the topic (Ajaxian). Did it matter that almost no-one was really fetching XML (the X in AJAX)? No.
"HTML5" played a similar role for a bunch of technologies 7-8 years ago, even including technologies that were nothing to do with the HTML5 spec (such as WebGL). Or DHTML 15-18 years ago.
We now see something similar with "serverless" which a lot of people criticize as a pointless term except it is bringing together discussion around a group of related concepts and is valuable in that role alone.
Other such terms that are ultimately ambiguous under close scrutiny but which allow discussion and communities to organize around them: IaaS, SaaS, NoSQL, devops..
Ajaxian - I can remember that. For a while it was a must read. Like 'Byte' in a generation before or 'Scientific American' a generation before that, 'Ajaxian' enabled you to learn about the future in a way where you felt quite privileged to be in on the story.
HTML5 also came with some publications that made you feel inspired. HTML5Rocks existed once. HTML5Doctor limps on with no content and someone paying the hosting much like Ajaxian does.
As per the model railway example given in this thread these are the leftovers from the original geeks that created the scene.
HTML5 became all about how you could embed video without a Flash player. The geeks thought it was all about semantic markup. But for the people that see words as just shapes on a page the 'video without Flash' bit was all they could relate to.
Absolutely nobody apart from a few HN people are using HTML5. That is no exaggeration. Go to any of those billion dollar web companies, check out the code and it is just Div Soup.
Go onto Wordpress. It is all Div Soup. There are no themes that use HTML5 beyond chucking in a 'header' and 'footer' tag here and there. Yet a third of the web is supposed to be powered by Wordpress.
Go onto a website builder service like Wix. Same story, yet more Div Soup.
We never got the XML bit of AJAX. It ended up 'AJAJ' if anything as it is just some JSON object that is what gets worked with.
With HTML5 we never got the semantic elements apart from the 'video' one. We got rounded buttons from CSS3 though.
I think the whole semantic thing was a mistake. The likes of Google have AI robots that can see pages and work out what is going on. So if you have a visually well designed page their robot is fine with that. Unless you are writing a page for the government's site on special needs then to hell with accessibility. That is how it seems.
The geeks that enthused about semantic HTML5 elements left the party a long time ago. The people who think HTML5 means you don't need flash took over and thought that was all there was to it.
The denial is an important thing though. People can keep working as they were before but believe they have new skills, adapted and changed.
I've always liked Dan Abramov's posts. He is very real, if that makes sense. This one really helps me mentally. Showing new work the world is hard, and people will always have something negative to say. There's also the issue of timing. When is it "too early" to show off a project? I always wanna post my projects to HN but then I remember how my documentation isn't done, or how I haven't written any tutorials or articles, and I figure I'd better wait, otherwise people will just bounce because they didn't find anything. I think the fraction of people who look at source code because they didn't find any docs is very small.
"By now, you’re convinced: This idea deserves to be heard."
This week my first public project got 7 git stars. The feeling is fantastic. I don't have homepage or story, but I have a nice diagram :)
The question for me is why I'm releasing this, to feed the ego monster or because I really beleive it's worth it? I hope it's not the first, but not sure, tbh.
It might as well be a combination of the two, but to be honest I don't think it's an issue. If those ego boosts are what keeps you building something useful, that's great and you probably deserve them.
It's a bit like social networks for exercise (Strava etc) - the whole thing is just people looking to show off because they've exercised, but if that's what's keeping them in shape, then great!
As a side note, I think you'll get a whole lot more stars with a screenshot and a one line description in the readme (before the mobile github fold for readmes)
Thanks for the writeup, Dan. This is how I feel about most code reviews. It's difficult to comprehend all the code and focus on the _actual_ problem being solved rather than naming conventions and syntax. And yes, I realize the irony by posting a tangentially-related comment on HN.
Wow, most of the comments in this thread completely miss the point, which... is the point. So meta.
We suffered this exact same issue for years, but it isn't only in git, readme or marketing pages that the problem exists. When pitching or telling people what we do, because what we are doing is new, we struggled to find the right words and therefore, got blank stares about what we were doing.
The same thing happens with the introduction of many new products and systems.
We have gone through many iterations of how to describe our product and the industry moves making it the next big thing. From "3d visualizations" to "interactive 3d scenes" and currently settling in on "spatial media". Each version gets successively better, but until you give someone a hook to hang your product on, they don't know what to do with it. That is the shared vocabulary.
For us, it goes like this.
"The future of media is spatial,viewers expect to be able to control their perspective in a 3d scene. We've seen this with VR, 360 video, and gaming. We are another type of spatial media. We're like drone shot video, but the viewer is in control of their perspective, and we create the scene without a camera."
With that description I still have no idea about what you actually do. Maybe that's not actually the pitch and you're just giving an example, or maybe not, just wanted you to give you my feedback :)
[on the subject of HN negativity raised in other posts—sorry for hijacking this post about post hijacking!]
One problem with HN, which I would love to hear othersʼ opinion about, is: the HN Guidelines incentivise negative colour in threads. You get 10 upvotes, and 1 critical comment: to anyone reading the entire thread now looks negative. Noone sees the silent "+1"s, which, I feel, do add a lot of positivity and encouragement!
I honestly don’t know what to change, or how. Hiding scores is great: it avoids the asinine karma peacocking, endemic in most similar forums. Allowing "+1" comments would probably be worse.
But the result is there. I think HN has a lot more positivity than we can see. But it remains hidden in the database.
Positivity on HN is write-only. Negativity is world readable.
My take on that issue is it doesn't matter in any regard. It couldn't be any more meaningless.
A scenario: a show HN post gets ~60 upvotes reasonably quickly and gets to the front page. Inside the post you have ten or so comments, three of which are negative or quasi negative (sometimes merely skeptical, sometimes overtly harsh). Two people really liked it and said so, five comments are mostly off topic. The negative comments are at the top in the thread (posted by members with higher default ranking scores); the positive comments are short on content and are near the bottom of the thread (posted by weaker ranking members).
That setup doesn't seem like it would be great. In fact it's spectacular. The post is going to end up with 100+ upvotes over time and it's getting a wave of traffic to it. It's the huge number of readers that never comment, and or never even sign up for an account, that are by far the most valuable part of the equation. The typical negative/cynical/skeptical comments are mostly meaningless - so long as you actually have a good product. I can't emphasize that enough, I need a far stronger word than meaningless here. You have a chance, with that wave of traffic, to convert people that want to believe in what you're doing - that's where all of your focus must be, those are the people you must not fail.
If it worked any other way in actuality, no product launch on HN would ever succeed. They'd all be buried by skepticism. It's the unseen angelic adopters on HN that matter more than anything else. Focus on delighting them and everything else will flow from it.
My advice on negative comments (unless they're definitely well earned, in which case you better act on them): put them in your mouth and eat them. Negative HN comments are like eating plain rice cakes. In the scheme of life, they're about the least concerning - most benign - things you're going to run into in the list of negatives when trying to build something, launch a product, run a business, and so on. Every other real problem with business or a product/project is drastically harder to push down and digest. At a minimum let the negative HN comments be a gentle introduction to how hard doing something successfully actually is (gentle because, again, negative HN comments are the easiest thing to mentally deal with - among negatives - that you will ever run into).
I find this to be spot on. I've frequently seen internal projects in companies called "Data Event System" or "Progam Manipulator" or some other nonsense. Sometimes giving a name to a project will dramatically change the way people talk about it.
The author's understanding is that these pepole would be discussing the project proper if they weren't discussing other things instead. I don't think he's right there. People love to talk and tend to flock to wherever conversation is happening. These people were never partciularly interested in discussing the project anyways; they were just browsing and saw an opportunity to jump into the discussion with something they do really care about, such as indentation styles or the nature of abstraction or what have you.
Also, the conclusion is a typical case of something that sounds insightful, but doesn't make any actual sense. I don't have even the slightest clue as to what the author is trying to say.
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 :-)
Well if the thing you're trying to create is really new (let alone zero to one), then it'll probably be difficult to explain concisely without ending up with several sentences full of "trivial" details.
I think Dan's example about irrelevant comments and the reasons behind it are clear, but the ending about naming and telling a story does not provide a good enough solution.
Not sure if his intention was to offer any solutions at all but I wonder if anyone anyone has found some great techniques that guides launching "completely new" ideas to market. (if you do please let me know)
When I look at the first ride-hailing companies or other zero to one companies it seems like they started out by:
1. Coining a definition.
2. Telling a story.
3. Ignoring irrelevant feedback.
4. A wide spread of calculated trial and error marketing, eventually one will do the magic.
I wonder to what extent this is determined by the platform? There is a kind of response that occurs on HN and every other platform I know that seems reflexive. I've tried at times and utterly failed to move from "commenting on" to "doing something" or "further discussion" and it just does not seem to work. Perhaps it is me but perhaps there is some other style or format that would provide a better vehicle. I find the concept of "name it and they will come" funny and interesting and would like to explore it more, but how?
I feel like it doesn't apply to just software projects, but it's a phenomenon that affects life more generally.
It's so much easier to bring our focus on and talk about what we understand that we might just dismiss what's truly important but requires effortful thinking.
Universal shared experiences are easy to talk about. That includes topics like code formatting, verbosity vs magic, configuration vs convention, differences in the community cultures, scandals, tech interviews, industry gossip, macro trends and design opinions.
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.
This is very accurate as of my recent experience on doing a Show HN here[1][2]. I did get very good feedback but many of the comments were just stupid. Still, posting here did help the project as the broader audience doesn't care about a random's HN opinion.
Weird, I actually thought of your Show HN post while reading this. I think this was because the response on HN seemed very negative, but then I saw the project was trending on Github for days after the HN post.
The post did help project take off. It's just a little annoying to read negative comments when we can easily convey the same point in a constructive way.
I still love this place and am a big lurker for a long time. I am pretty sure if we were a bit more humane, many many lurker will actively participate, which would be a win-win.
Agreed, the comments in your thread were deplorable (to a large extent). Be aware that most people on HN simply appeal to high profile personalities and don't really have the judgment to deem something usable or not. IMNSHO, that is.
Its relevant, its concrete, I agree with everything he said. But mostly I just got caught up in his writing-style which is incredibly enticing. Well done man!
The title of the article is the best part. Naming your new thing and owning the meaning of that name is valuable. The rest of the article is much weaker.
>> Usually, you feel like you’re creating something. But this time, it feels like you are discovering something as if it already existed.
I can relate to this.
>> It’s not that people didn’t like the project. You know it has tradeoffs and expected people to talk about them. But that’s not what happened.
>> Instead, the comments are largely irrelevant to your idea.
I can't relate to this part. I authored a somewhat popular open source server/framework project (over 5k stars on GitHub now) and my main problem for years was that there weren't enough people using or commenting on it.
The few people who were commenting on it over the years were consistently and exclusively giving positive feedback. Someone even wrote their master degree thesis about my project's scalability and performance. Developers started writing many clients libraries for it (there are now clients in pretty much every major language including more obscure ones such as Unity and one is currently being written for Unreal Engine).
For 5 years, I was constantly searching for criticisms and problems to justify why my project wasn't more popular (so that I could fix the problems) but nobody offered any criticism. Instead people kept telling me that the project was underrated and deserved more attention.
It's pretty heavily used now; it gets a lot of downloads on npm, for some reason, it just got steady linear growth and still it doesn't get talked about much. Now I'm thinking that maybe the problem is simply that I'm not active on Twitter.
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.
> Finally, it’s the launch day. You publish the project on GitHub. You tweet about it and submit the landing page to the popular open source news aggregators.
What are some popular open source news aggregators oter than HN?
I'm not really seeing what you would gain with a story in this context. If your project "hit the front page of a popular news aggregator" I would say is because you already have the story.
If you toggle the dark/bright mode enough time, your eyes will hurt. You will come to the conclusion that only the dark mode is enjoyable and readable.
I can see why. HN is not for very divergent submissions, they rarely take off here. Your submissions are kinda not-so-familiar to the great masses so they don't fly. People just being curious without being familiar with the subject won't check them out because the number of upvotes haven't reached a critical level.
Try something more populistic, and especially deriving from an established trend, and I think you'll appeal to the mob. How about: "ReactJS rewritten in Go in 24hrs"
am i the only one who was expecting him to say, after he had posted his project to HN, he would got no upvotes and sadly his project remained invisible to the public?
because getting to front page on news site like HN/Reddit, there is some luck factor too, kind of like winning a lottery, unless you learned to gamify it.
This made sense until the last line. If the conclusion was "focus on telling your story well so that people understand the point of your work," I would understand that. But he concludes with "name it, and they will come." So... he's saying that your product needs a good name? I don't get it.
I’m waiting for a comment about why the author chose to Write the fictional project in JavaScript to take the top comment spot and the language wars to begin....
= = = =
The top comment thread picks on the coding style in a README example. It turns into an argument about indentation with over a hundred replies and a brief history of how different programming languages approached formatting. There are obligatory mentions of gofmt and Python. Have you tried Prettier?
Somebody mentions that open source projects shouldn’t have beautiful landing pages because it’s misleading marketing. What if a junior developer falls for it without fully understanding the fundamentals?
In a response, somebody argues the landing page design is boring. Additionally, it’s broken in Firefox. Clearly, this means the project author doesn’t care about the open web. Is the web as we know it dying? It’s time for some game theory…
The next comment is a generic observation about the nature of abstractions, and how they can lead to too much “boilerplate” (or, alternatively, “magic”). The top reply explains that one shouldn’t confuse “simple” with “easy”. Actually, Rich Hickey gave a very good talk about this. Have you watched it?
Finally, why do we need libraries at all? Some languages do well with a built-in standard library. Is npm a mistake? The leftpad accident could happen again. Should we build npm right into the browser? What about the standards?
Confused, you close the tab.