Hacker News new | past | comments | ask | show | jobs | submit login

The counterargument is that, just as with downvote-reason-giving, downvote-reason-reviewing would be dominated by the same forces as downvoting in the first place. You wouldn't get more signal, just more complexity, plus a lot more work—both because of the reviewing itself, and because of meta-quarrels about reasons and reason-reviews. One thing many HN users may not realize is that we don't have a lot of capacity to take on more work managing HN. We operate more or less at our limit, with frequent bursts over the limit when the needle goes into the red for whatever reason. One of the more interesting variables that regulates how HN functions is how much of this we can stand to do. You might think that's a simple problem of hiring more, but that comes with tradeoffs too. Rather than making HN more complicated and then making the operation more complicated to handle the increased load, we'd rather resist temptation in the first place.

HN's approach is to stick with something simple, accept that it has downsides as well as upsides, and resist the temptation to fiddle with the downsides by sacrificing simplicity. It's a strong temptation for a technical person to want to do that, of course, but there's a strong story why the downsides of downvoting are mostly intrinsic: disapproval stings. Most of what people say when they complain about the downvote system seems to boil down to that. That's not a technical problem. If there's something we can do to mitigate it, it would more likely come from helping the culture to evolve. I do think that's happened, and is happening, a little; it's just very slow.

You can't draw conclusions from how downvoting works on, say, lobste.rs to what HN should do. With online communities, size is the dominant variable. When there are order-of-magnitude size differences between communities, that is what explains why things work differently there—not subtle software design choices. Similarly, one can't draw conclusions from how HN works to much larger sites like Reddit. One of the nice things about HN not having to try to grow ambitiously (it has grown linearly at more or less the same slope for many years) is that we can focus on being the best HN-sized-thing we can be. That leads to subtler, more qualitative kinds of growth.

A couple more points that bang around in my head when issues like this come up...

One form of complexity that's particularly important to resist is adding metadata and creating metasystems in order to compensate for things in the core system. The magical charm of all things meta gives that step a perennial allure. But it's a step with major consequences and often a mistake. If you go meta to handle something that isn't truly orthogonal to the core system, you end up with more of a mess. I think we have a case of this here. For example, when a comment is wrong, the way to address that is to reply with correct information. Why do we need a popup with a "wrong" selection? The core system—HN threads—can already accommodate this function; we don't need a metasystem for it. Of course it doesn't accommodate it perfectly, but the imperfection is not for technical reasons, it's because people don't always agree about what's right vs. wrong, and so on. A metasystem doesn't fix those things, it just recreates them on another level. And now, as they say, you have two problems, plus the problem of how the two interfere with each other.

It gets worse. With any system, there are only so many complexity cards you get to play. Each time you play one, you lose the chance to use that card for something else. What we see over and over in the software world is that, because people don't know this and because they're under pressure, a system blows through its complexity budget—plays all its cards—right at the beginning of its lifecycle, depriving it forever of the chance to be coherent or tractable as it grows. This is the root of the fatalistic complaints about software bloat that commonly come up in HN discussions, as well as the constant yearning to create new systems rather than be stuck, as most of us are, fiddling with a couple screws in some rusty component of a massive machine that nobody understands. It happens that, from a technical point of view, HN is a rare exception to this pattern. For a bunch of reasons, two of which were pg's minimalism and Lisp sensibility, and another of which was perhaps that the project has always been resource-constrained, HN escaped the fate of becoming more complex than it needed to be. Preserving that quality is a priority, because it allows us to work with the system in rich ways that are impossible on most production software projects.


Selfishly, I would appreciate it if HN would adopt downvote reasons because Lobsters has to acculturate people used to how HN does things. Occasionally they're outraged that we do not have downvote-to-disagree when a mod contacts them to ask that they stop picking random reasons to do so. If HN would be so kind as to train several million programmers in the UI and norms I'd appreciate it.

Less tongue-in-cheek, I do think flag/downvote reasons are worth the added complexity for us, but as there's a cultural component to these design issues it's probably a non-starter for HN to adopt. A change in such a fundamental interaction on the site would be an upheaval that's not justified by probability and size of an expected benefit.

+1 on basically your entire message, especially recognizing the limits of mods and size as dominant variable on roughly everything to do with communities. Best of luck.

Applications are open for YC Winter 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact