5 ms·

Contrarian opinion here. While things can always be better the Github UX is good enough here. I am reminded of an old phrase: “A bad workman always blames his

by davedx 5y ago

Contrarian opinion here. While things can always be better the Github UX is good enough here. I am reminded of an old phrase: “A bad workman always blames his tools.” At some point you just need to accept responsibility for your actions and stop blaming others.

hutzlibu 5y ago
“A bad workman always blames his tools.” It is a workman, who builds a very succesful tool for others. Not a bad workman by my definition. And his suggestions of improving the UI sound very solid. Also I am not sure, if you got the part, where he pointed out, that Github themself made the same misstake for one if their repos. Sure, sure, all bad workman.
matsemann 5y ago
> “A bad workman always blames his tools.” That's a meaningless statement, though, as it can always be used against anyone complaining about something. I mean, you yourself wrote this the other day: > I had to work with SAP Hybris a year or two ago. My IDE was not smart enough. Well actually I spent a good number of days trying to configure my IDE to be able to work properly with Hybris. I failed. What a mess Are you a bad workman blaming your tools? Or do some tools just genuinely have faults?
- Kronen 5y ago
  he said "I failed" not "the tool failed"
  - matsemann 5y ago
    While lamenting the tools. They also wrote "my IDE was not smart enough".
FeepingCreature 5y ago
Good workmen also blame their tools. Because sometimes tools are bad, and that's how they get improved.
raldi 5y ago
Completely disagree; when it comes to programming (where all tools are infinitely malleable), it’s a poor programmer who puts up with suboptimal tools.
abuggia 5y ago
I don't think he's blaming HN to the point where he's shirking responsibility for what he did. I read this post as a clever way to get play on HN which will help him get some of his stars/watchers back.
fourseventy 5y ago
Couldn't agree more. The author not only messes up his own repo while blaming the GitHub UI, he proceeds to then whine that GitHub employees won't restore his data from a backup.
- hutzlibu 5y ago
  But the point he makes, is that Github made the same misstake - and for themself they could restore it.
- user_7832 5y ago
  If it's a mistake that even a GitHub employee can make with very heavy consequences, is that entirely the fault of the author? When Lauda Air Flight 004 crashed because the pilots accidentally deployed the reverse thrusters in air, even though it was the pilot who "made a mistake", Boeing was forced to change their design and now the original design is considered flawed.
kif 5y ago
Maybe the UX is not great, but surely having to type "httpie/httpie" would have given me a pause. Regardless, to make mistakes is human. What I don't really like is how the author starts attacking Github and Microsoft, just because they can't afford to fix the author's mistake. A huge red flag for me.
- hombre_fatal 5y ago
  Once you do it a few times, writing the repo names means nothing. You have to do it on your repo with 0 followers just making it public. It’s not very notable unless you’re new to Github. My advice is for Github to tell you that you’re losing 53,000 stars (not just “all your stars”) to help knock you out of autopilot. I don’t get the finger pointing though. Obviously they messed up, it’s the entire post. But it’s also a good moment to reflect on how UX can be used to prevent people from messing up.
  - barrucadu 5y ago
    What should the threshold be? 53,000 stars? 50,000 stars? 25,000? 100? No matter what number you pick, there will be someone with fewer stars who considers their stars important enough to merit a warning. Unless you set the threshold to 1, in which case it's just more meaningless noise, like the repository name (apparently) is.
    - ric2b 5y ago
      Always show the number if it's more than 0. It's more informative and might catch your attention better than "something bad might happen"
- electroly 5y ago
  They didn't say so, but 100% they copy-pasted the name from the prompt. I always do. They didn't type manually it in a way that would help them catch the error. That's a big reason that "enter this thing: ______" isn't foolproof. Perhaps it should at least be made unselectable.

by davedx 5y ago

hutzlibu 5y ago

“A bad workman always blames his tools.” It is a workman, who builds a very succesful tool for others. Not a bad workman by my definition. And his suggestions of improving the UI sound very solid. Also I am not sure, if you got the part, where he pointed out, that Github themself made the same misstake for one if their repos. Sure, sure, all bad workman.

matsemann 5y ago

> “A bad workman always blames his tools.” That's a meaningless statement, though, as it can always be used against anyone complaining about something. I mean, you yourself wrote this the other day: > I had to work with SAP Hybris a year or two ago. My IDE was not smart enough. Well actually I spent a good number of days trying to configure my IDE to be able to work properly with Hybris. I failed. What a mess Are you a bad workman blaming your tools? Or do some tools just genuinely have faults?

Kronen 5y ago
he said "I failed" not "the tool failed"
- matsemann 5y ago
  While lamenting the tools. They also wrote "my IDE was not smart enough".

FeepingCreature 5y ago

Good workmen also blame their tools. Because sometimes tools are bad, and that's how they get improved.

raldi 5y ago

Completely disagree; when it comes to programming (where all tools are infinitely malleable), it’s a poor programmer who puts up with suboptimal tools.

abuggia 5y ago

I don't think he's blaming HN to the point where he's shirking responsibility for what he did. I read this post as a clever way to get play on HN which will help him get some of his stars/watchers back.

fourseventy 5y ago

Couldn't agree more. The author not only messes up his own repo while blaming the GitHub UI, he proceeds to then whine that GitHub employees won't restore his data from a backup.

hutzlibu 5y ago
But the point he makes, is that Github made the same misstake - and for themself they could restore it.
user_7832 5y ago
If it's a mistake that even a GitHub employee can make with very heavy consequences, is that entirely the fault of the author? When Lauda Air Flight 004 crashed because the pilots accidentally deployed the reverse thrusters in air, even though it was the pilot who "made a mistake", Boeing was forced to change their design and now the original design is considered flawed.

kif 5y ago

Maybe the UX is not great, but surely having to type "httpie/httpie" would have given me a pause. Regardless, to make mistakes is human. What I don't really like is how the author starts attacking Github and Microsoft, just because they can't afford to fix the author's mistake. A huge red flag for me.

hombre_fatal 5y ago
Once you do it a few times, writing the repo names means nothing. You have to do it on your repo with 0 followers just making it public. It’s not very notable unless you’re new to Github. My advice is for Github to tell you that you’re losing 53,000 stars (not just “all your stars”) to help knock you out of autopilot. I don’t get the finger pointing though. Obviously they messed up, it’s the entire post. But it’s also a good moment to reflect on how UX can be used to prevent people from messing up.
- barrucadu 5y ago
  What should the threshold be? 53,000 stars? 50,000 stars? 25,000? 100? No matter what number you pick, there will be someone with fewer stars who considers their stars important enough to merit a warning. Unless you set the threshold to 1, in which case it's just more meaningless noise, like the repository name (apparently) is.
  - ric2b 5y ago
    Always show the number if it's more than 0. It's more informative and might catch your attention better than "something bad might happen"
electroly 5y ago
They didn't say so, but 100% they copy-pasted the name from the prompt. I always do. They didn't type manually it in a way that would help them catch the error. That's a big reason that "enter this thing: ______" isn't foolproof. Perhaps it should at least be made unselectable.