Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We lost 54k GitHub stars

httpie.io

Post reply on HN
Print view View original

611–620 of 697 posts

Re: We lost 54k GitHub stars

#611

Post by mypalmike »

14u2c wrote: post #393
lalopalota wrote: post #303

Earlier quoted context omitted.

Right, just more work. More tests. More edge cases. More time.

Well, they put in the time to test a massive cascading delete operation. Surly a flag would have offered far less possibility of catastrophic outcomes and therefore would been significantly easier to confidently develop and test.

If they are using a database's built in support for cascading deletes, and if the star tables are simple m2m tables (basically just 2 fk's per row), the work to implement and test cascading deletes is trivial.

Re: We lost 54k GitHub stars

#612

Post by Macha »

prepend wrote: post #559
derefr wrote: post #288

Earlier quoted context omitted.

If your whole job is to use power-tools, the fact of using power-tools by itself — scary to some — becomes benign for you. `rm -rf` isn't scary to type if you e.g. write CI scripts intended to run in sandboxes all day. Deleting a repo isn't scary if you delete a lot of pointless repos. A prompt that pops up to warn you that you're doing something potentially dangerous, when you know that what you're doing is benign,…

This is a good point and reminds me a story of many years ago when someone accidentally ran “rm -rf” on an important directory and caused a lot of work. A well-intentioned PM then thought the fix was to alias rm and add prompts to confirm. They had a whole project to add this alias everywhere. First it broke existing scripts all over the place. So they fixed them to auto apply the confirmation. Cut to a few months la…

Yeah, aliases for "rm" to "rm -i" I find are especially counter productive in this regard, as it conditions people to type rm -f after they get spammed to approve several hundred files while trying to delete a git checkout or node modules too many times.

Re: We lost 54k GitHub stars

#613

Post by TAForObvReasons »

media-trivial wrote: post #606
sunir wrote: post #585

Earlier quoted context omitted.

I don’t see the need for moralizing. They took responsibility, and offered GitHub money to help. They aren’t leaning in heavily to blame Github here. It’s fine to express the gulf of evaluation and execution that led to the error. It happened. There may not be any better known solutions at the moment to lower the risk any further. Calling them careless is also unjustified. They made a mental error processing the info…

> and offered GitHub money to help It's not like they can just run a few SQL queries on prod and have the author PayPal them 10$. They need to create a plan, cost estimate, risk assessment, get management/qa/security/SRE/... approvals, write the code, documentation, reviews, tests, run on prod, create invoice, etc. This means 10-20 people work for 1-2 days. I doubt that the author is willing to pay 20000-60000$ for t…

https://httpie.io/ has a star display on the homepage, and the story https://httpie.io/about alludes to the star count:

> That humble tool, which we open-sourced, quickly captured developers’ hearts and rapidly became one of the top projects on GitHub.

> We’ve raised a Seed Round ...

It's not hard to believe the seed round and the entire pitch of the commercial venture was tied to the star count, and it's not hard to believe that the author would drop $1/star to restore the count.

Re: We lost 54k GitHub stars

#614

Post by sbarre »

farmerstan wrote: post #457
sbarre wrote: post #279

Earlier quoted context omitted.

Ok then. I hope others are less judgmental of you than you are of them next you make a mistake in life.

I take ownership over my mistakes. I don’t try to blame others. The world would be a better place if everyone did that.

I believe the world would be a better place if we all showed a bit more compassion towards each other, but let's agree to disagree.

Re: We lost 54k GitHub stars

#615

Post by glacials »

parkingrift wrote: post #583
dmitshur wrote: post #572

Earlier quoted context omitted.

I’m wondering if you got a chance to see this part of the post: > […] I obviously had no intention to make httpie/httpie private. So, why then? > > The proximate cause was that I thought I was inside a different repo; […] What I actually intended to do was to hide the HTTPie organization’s profile README, […] > > What put me on the wrong path was an otherwise completely unrelated action: I had just done the same (i.e…

I did read that part. He or she had to exactly type out "httpie/httpie" to confirm the action. I don't know what else GitHub could do to prevent this. How much handholding does GitHub need to offer? People need to accept the consequences of their own actions. The amount of manual steps necessary to take httpie private is fairly substantial. This person was careless and learned a lesson on being careless.

Based on your phrasing I’m still not sure if you understand parent—yes, the author had to type “httpie/httpie”, but due to GitHub’s user-level README repo feature, _that specific repo name_ conventionally would be a README repo, which is what the author was trying to delete.

For example, my README repo is and must be called “glacials/glacials”; if I wanted to delete it that is what I would type, but if I were an organization and wanted to delete it, I would type something else. This different behavior between acting as a user vs. acting as an organization is what caught the author off-guard. They typed “httpie/httpie” and consciously thought “yes, I want to delete the README repo, which I know must have name httpie/httpie, so that’s definitely what I’d like to do, I’ll go ahead and type that”.

This is not absentmindedness, it is a misleading product inconsistency. Were it not for this, I would 100% agree with you.

Re: We lost 54k GitHub stars

#616

Post by chefandy »

chefandy wrote: post #285
mynameisvlad wrote: post #239

Earlier quoted context omitted.

> I'll bet the list of side-effects that are important to some people would be pointlessly long. There's many good ways to design this that wouldn't result in pointlessly long lists (which is another problem). You don't need to expose everything that will happen when you do an action, just the "most important". With unlimited budget, you could compare a bunch of metrics to a baseline to figure out what might be impor…

You assume the metrics you have are sufficient to determine intent and importance, that your users needs are uniform enough for those determinations apply, and discount the possibility of making things worse by communicating the wrong thing. These assumptions perennially land developers and inexperienced designers in hot water designing things like this. > "most important" Yes— the problem is determining the most imp…

Anyone wanting to dig deeper into the design side of this should check out Triadic Semiotics— it's the philosophy of signs.

Re: We lost 54k GitHub stars

#617

Post by farmerstan »

sbarre wrote: post #614
farmerstan wrote: post #457

Earlier quoted context omitted.

I take ownership over my mistakes. I don’t try to blame others. The world would be a better place if everyone did that.

I believe the world would be a better place if we all showed a bit more compassion towards each other, but let's agree to disagree.

I am very compassionate towards their loss. It must suck to have mistakenly destroyed their community. However I draw the line when they falsely blame others for their own mistake.

You can be compassionate for a mistake and still insist someone take ownership over this own careless error instead of blaming others. You mistake compassion for “let them do or say whatever they want because they are a victim”.

Re: We lost 54k GitHub stars

#618

Post by wpietri »

chefandy wrote: post #215
mynameisvlad wrote: post #163

Earlier quoted context omitted.

This, 1000x this. It's easy to be an armchair engineer and say "well, obviously, don't make this mistake in the future". As a species, we will always take shortcuts. If a mental pathway doesn't need to be exercised to do something, it won't be. If we see the same popup a hundred times, we're going to ignore the contents by the 100th time because we're used to it. But it shouldn't be possible to make this mistake if t…

Pretty much agree— Universal human fallibility is not an avoidable moral failure, but looking down on those who've made, admitted, and taken responsibility for simple mistakes sure is. Unrealistic assumptions about people's attention, processing capability, and physical capabilities may be the greatest hurdle when trying to actually solve people's problems with software. It can even be a safety issue— consider the Th…

> The challenge screen does require typing in the repo name which is a pretty solid attention-getter.

This is not quite correct. In requires inputting the repo name. It's attention-getting the first time. But recently with some colleagues as part of a handoff we went through 50+ repos and archived the irrelevant ones. Very quickly the person doing the actual archiving went from typing to just copy-pasting the repo names. For programmers, copy-pasting from one spot to another can become very mechanical.

So I think this UI choice works well for something that is done very occasionally. But it's no better if people are in the habit. Whereas showing novel information about the cost of the choice would be helpful in breaking the routine. Then could then also make it so that they had to type something only when the operation has a high cost, and what they typed could be something not directly copy-pasteable.

Re: We lost 54k GitHub stars

#619

Post by wpietri »

react_burger38 wrote: post #328
wpietri wrote: post #123

Earlier quoted context omitted.

I suggest you read "The Field Guide to Understanding 'Human Error'". You'd learn a lot. https://www.amazon.com/Field-Guide-Understanding-Human-Error... My view is that expecting humans to stop making mistakes is much less effective than fixing the systems that amplify those mistakes into large, irreversible impacts.

This idea - fixing systems that amplify mistakes into large, irreversible impacts-- is why I am against alcohol, marijuana and other mental-state altering drugs for recreational purposes. (I'm not talking about people who really need pain relief from cancer, amphetamines for ADHD, etc.) If no one in the world drank, smoked pot, or did drugs, how much better off would we all be? 100,000 deaths come from alcohol use ev…

You haven't really thought this through.

One, those substances are fine for a lot of people.

Two, some of those substances are fine for most anybody. I've never even heard of a deadly marijuana overdose, and the evidence shows no increase in mortality for marijuana users.

Three, we already tried alcohol prohibition, and we are currently trying drug prohibition. It does not solve he problem you care about, while creating other large problems.

So really, you sound like somebody who has a personal hobbyhorse and uses pretty much anything (like say, losing stars on GitHub or mentioning a book on airplane safety investigations) to argue for it. And that sort of motivated reasoning around argument for societal change strikes me as way more dangerous than somebody eating a THC edible.

Re: We lost 54k GitHub stars

#620

Post by wpietri »

krick wrote: post #366
wpietri wrote: post #123

Earlier quoted context omitted.

I suggest you read "The Field Guide to Understanding 'Human Error'". You'd learn a lot. https://www.amazon.com/Field-Guide-Understanding-Human-Error... My view is that expecting humans to stop making mistakes is much less effective than fixing the systems that amplify those mistakes into large, irreversible impacts.

Is that book still worth to spend time reading if I do understand what you are saying and I hold the same views? I'm always hungry to learn something useful from books, but more often than not I find these hyped books ("The Checklist Manifesto" comes to mind) really annoying in that they make me spend a significant amount of time reading stupid "curious life stories" to bring across a point that can be expressed in a…

It's an incredibly rich book. I learned a ton from it. Indeed, I avoided summarizing it here precisely because it's hard to sum up.
Post reply on HN