471–480 of 697 posts
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.
The penalty for sin is death.
The wages of sin is death.
I really like this post. While the author clearly feels bad about the fact that they've lost his community and that GitHub didn't restore it (which is honestly what any of us would've felt under similar circumstances), they're also focusing towards the future and using their personal experience as a parable all of us can learn from. Lesson 1 on UI design I think is really important. I often think scary popup boxes ar…
Github is built with MVC. On rails no less. Where problems like soft delete are hard, or even impossible to solve (in scale). Yet there are many architectures beside MVC. Many of them decades old. Proven. Established. Yet unknown to devs who picked up a rails book on day 1 and never looked back (I've been guilty of that for years). This particular problem is a textbook candidate for Command Pattern. The problem of un…
This comment seems to be down on MVC and Rails so I was curious about the alternatives you mentioned and came across your post that ended with praise of Rails ( https://berk.es/2022/03/08/the-waning-of-ruby-and-rails/ ):
> Rails still is a great way to get a prototype demo, or minimum viable product online in days with least surprises.
Your comment seems to indicate that you started discovering new architectures like the Command Pattern but it sounds like you are also still a proponent of Rails and MVC based on your blog post. Do you have any links to resources that helped you discover other patterns or could you share what took you on your journey?
In the Rails blog post, you said:
> I have a separate post planned on "RAD web frameworks", MVC and ActiveRecord, but it is safe to say that such frameworks, amongst which Rails, have found their niche, yet are by no means a silver bullet.
Is that post you are planning to write going to delve into some of the architectures you mentioned here? That would definitely be something I would be interested in reading.
Earlier quoted context omitted.
"Type a specific thing to confirm" (as suggested by the post you linked) is exactly what Github does for destructive actions. And the author still messed it up because they were on "autopilot". At that point the suggestions go beyond being reasonable.
So you never copy and pasted into dialog boxes? This is exactly the same thing as the Windows warning messages were they found that nobody reads the because they are being trained to click them away. The main thing I really don't get is why it even needs to delete all the stars? It's not like they delete all comments/issues... by users who have been deleted. So why could they not simply make the star point to a "ghos…
I really like this post. While the author clearly feels bad about the fact that they've lost his community and that GitHub didn't restore it (which is honestly what any of us would've felt under similar circumstances), they're also focusing towards the future and using their personal experience as a parable all of us can learn from. Lesson 1 on UI design I think is really important. I often think scary popup boxes ar…
I specifically dislike the "Lessons" section, as it throws all the blame on github and doesn't mention the seemingly obvious advice: "make sure you're not on autopilot when taking potentially dangerous actions, on github or any website". Yes, GitHub probably should show the stars in the warning UI, and hopefully that will prevent some of these mistakes. But GitHub makes it pretty hard to make this mistake already - t…
“I take responsibility, but…” is not “I take responsibility.”
Earlier quoted context omitted.
Github is built with MVC. On rails no less. Where problems like soft delete are hard, or even impossible to solve (in scale). Yet there are many architectures beside MVC. Many of them decades old. Proven. Established. Yet unknown to devs who picked up a rails book on day 1 and never looked back (I've been guilty of that for years). This particular problem is a textbook candidate for Command Pattern. The problem of un…
1. Why would it be particularly difficult for them to have soft deletes in Rails or at scale? 2. Like the article suggests, additional UX improvements could be made besides making it possible to restore a backup or providing an undo action. 3. I feel you are ignoring the fact that technology-wise it was probably Rails along with its MVC model that got them into their scale in the first place. 4. Had they focused on a…
I don't know the internals of Github. But we had soft-delete dragging down our database. Indexing, for one, becomes tough.
It also presumes everything lives in a single, canonical, transactional database. In real life, anything of scale, with legacy lives in multiple services. There'll be caches, search-indexes (elastic etc), data-lakes, leader/follower clusters and whatnot. Propagating a "delete" command is no easier or harder in such a setup, than propagating a "flag" which has severe business and security implications.
2. Like the article suggests, additional UX improvements could be made besides making it possible to restore a backup or providing an undo action.
Yup. My point was that with e.g. Event-sourced or Command pattern, you don't even need that whole UI in the first place. There could be a 20 minute "undo" somewhere. Or an "undo" that remains active untill another non-compatible command renders undoing unavailable. This is a common pattern. Which was invented decades ago, and is still used everywhere to solve this exact problem.
Why invent dialogs, soft-deletes, etc, when the problem is solved, done and non-existent, given you make the right choices? Why do software engineers insist on re-inventing wheels every few years rather than grab existing, proven and solid solutions for this?¹
3. I feel you are ignoring the fact that technology-wise it was probably Rails along with its MVC model that got them into their scale in the first place.
Why do you feel this? Rails comes with tradeoffs. I'm not saying "rails was a bad choice" But I'm saying "the choice for Rails brings the tradeoffs that e.g. Undo is hard".
Saying that "it is easy in Rails" is both disingenuous and unfair: there are hundreds of Gems, some of which grown to enormous project almost the size of entire ActiveRecord itself, to tackle these problems: it isn't easy. Papertrail, for example is a magnificent monster. "just drop in papertrail" really is not a solution, it's a problem.
> 4. Had they focused on a more exotic architecture from day one, the UX of other features on the site could've been significantly worse.
I.e. "tradeoffs".
¹ The answer, I'm afraid, is a mix of the doubling-of-developers-every-four-years (forever september), NIH, and unwillingness to invest time in learning the foundations layed out in the past decades. The last is what bothers me most.
That's crazy that a manual error by someone, for whatever reason, end up being an article blaming Github for all sort of reasons. And never accepting that the thing that really failed here is the user who performed the action.
With that mindset, planes would still fall out of the sky every month. Because basically 90% of plane crashes used to be "pilot error". If you then say, well, it was pilot error, bad pilot, can't do anything about it, that's the way it is, pilot should've not made an error... well, then we wouldn't have reached the amazing aviation safety we have now.
You missed that besides fixing UX, we also train pilots to think about their actions, talk to copilots about their actions, take responsibility for their actions and most importantly, not to press buttons on "autopilot".
That's a completely different situation and defending learned stupidity of just clicking ok to everything.
In America, we blame individuals when systems fail. We don't have to, we can actually design systems to be better. Design isn't just about making things look pretty. Good design reduces entropy. https://www.youtube.com/watch?v=Ra_0DgnJ1uQ https://en.wikipedia.org/wiki/Human_factors_and_ergonomics
Thankfully there are exceptions to this, notably aviation. Having all accidents investigated by an independent board with a systems approach has proven to be an extremely successful model. It's a shame it isn't replicated elsewhere.
Earlier quoted context omitted.
Warnings are good but not perfect. At the end of the day, you can’t help everyone with just warnings. You could make the UI bright flashing red, with a skull and crossbones, have it say “Never invoke this: it will delete all your data and kill your dog. Please type ‘I_WANT_CANCER’ to continue.” And users will do it. It can’t be helped. The only (admittedly hard) way is UNDO.
It's a real strength of Gmail and some other Google interfaces — undo instead of warning dialog.
Earlier quoted context omitted.
I specifically dislike the "Lessons" section, as it throws all the blame on github and doesn't mention the seemingly obvious advice: "make sure you're not on autopilot when taking potentially dangerous actions, on github or any website". Yes, GitHub probably should show the stars in the warning UI, and hopefully that will prevent some of these mistakes. But GitHub makes it pretty hard to make this mistake already - t…
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.
From an individual user's perspective, you still need own your shit and avoid making these mistakes. You can't rely on everything you use having smart safeguards.
There will always be dumb/careless users that a product should consider. There will always be suboptimal UI (we could've just as easily been talking about CLI database tools) that a user should watch out for
I really like this post. While the author clearly feels bad about the fact that they've lost his community and that GitHub didn't restore it (which is honestly what any of us would've felt under similar circumstances), they're also focusing towards the future and using their personal experience as a parable all of us can learn from. Lesson 1 on UI design I think is really important. I often think scary popup boxes ar…
I specifically dislike the "Lessons" section, as it throws all the blame on github and doesn't mention the seemingly obvious advice: "make sure you're not on autopilot when taking potentially dangerous actions, on github or any website". Yes, GitHub probably should show the stars in the warning UI, and hopefully that will prevent some of these mistakes. But GitHub makes it pretty hard to make this mistake already - t…
Where does it say that they deleted any repo?