Name It, and They Will Come
overreacted.io
overreacted.io
= = = =
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.
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."
> 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."
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.
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.
/rant
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.
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.
The reason the internet has more noise than signal is because there are many people, and they don' all want to talk about the same thing as you.
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.
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.
Whether it would improve the quality of the comment sections is an interesting question. I'd be interested to see that tested somewhere ...
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.
Or that's my interpretation of the article anyway.
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).
What's important is if it's better than the baseline of not doing what he suggests.
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?
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.)
[0] https://redux.js.org/advanced/middleware
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 :)
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!
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."
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.
That we knew already though. It's a free country, and everything.
And I'm not sure his examples with the comments diverting into "landing pages" and such are meant in a good light of those making such comments.
Wait, is that what it's called? The Naming Problem?
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.
> 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.
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.
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.
An example of an independent developer (browsh) shaping the conversation to their benefit: https://news.ycombinator.com/item?id=17487552
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 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.
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.
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.
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.
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.
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.
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..
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.
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'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!
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."
"We're like drone shot video, but the viewer is in control of their perspective"
Most people get that.
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.
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).
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.
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 :-)
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.
Is there a better way?
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.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.
1. https://zeroserver.io/ 2. https://news.ycombinator.com/item?id=19254828
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.
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.
If you are publishing a paper about new way to optimize a problem, just give it a fancy name first.
What are some popular open source news aggregators oter than HN?
Sorry, if it's true.
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"
That was a jest, by the way...
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.
Also, what's with the newsletter?
And why is this on a private blog, not something truly open? I can't even pull this using git?