5 ms·

Been there, done that. The paradox is that every device I use interrupts me non-stop with modal dialogs ad nauseam. But the production delete? You said,"drop"

Been there, done that. The paradox is that every device I use interrupts me non-stop with modal dialogs ad nauseam. But the production delete? You said,"drop", we said, "gone". Either production database deletes need to adopt alert fatigue or the ops are already so fatigued that it doesn't matter.

ilyt 3y ago
I'm pretty annoyed by those prompts. Yes, fuck you, do what I fucking said, my backups work fine. Also frankly I think most software does it wrong, if it is possible it shouldn't ask before delete but just allow to undo the step easily. Then work can go fast and uninterrupted while still being resilient to mistakes. Obviously not possible everywhere but where it is it should be the default.
- Xylakant 3y ago
  Cool that you have a working backup, but restores are what counts. And they’re not instantaneous in almost all cases. So asking before certain destructive actions is still a good practice.
- darkwater 3y ago
  > Also frankly I think most software does it wrong, if it is possible it shouldn't ask before delete but just allow to undo the step easily. Obviously. When undoing is not easy or possible automatically, there is the "Are you really really sure?" dialog.
Aerroon 3y ago
>The paradox is that every device I use interrupts me non-stop with modal dialogs ad nauseam. Pop-up warnings that are too common are a problem itself. People get so used to accepting them immediately that they stop serving their purpose and just become an annoyance. With one exception: they can prevent misclicks.
- davidthewatson 3y ago
  Right! That's why I used the term alert fatigue: https://en.wikipedia.org/wiki/Alarm_fatigue https://en.wikipedia.org/wiki/Alarm_fatigue The misclick point is beyond truth, particularly given the storm of marketing that is mobile web.
taneliv 3y ago
In a company where we chose to do production SQL shenanigans in the spirit of "move fast, break things", I developed a habit of starting those with "BEGIN;" and paying careful attention to the number of records modified before calling it a "COMMIT;". In case of unexpected numbers, immediate "ROLLBACK;" so as to not hog the resources and make the applications suffer. Even fatigued, "DELETE 1182900" tends to stick out, if you're used to, and expecting to, see "DELETE 1". ("BEGIN" appears to be PostgreSQLism, "START TRANSACTION" is more standard.)

ilyt 3y ago

I'm pretty annoyed by those prompts. Yes, fuck you, do what I fucking said, my backups work fine. Also frankly I think most software does it wrong, if it is possible it shouldn't ask before delete but just allow to undo the step easily. Then work can go fast and uninterrupted while still being resilient to mistakes. Obviously not possible everywhere but where it is it should be the default.

Xylakant 3y ago
Cool that you have a working backup, but restores are what counts. And they’re not instantaneous in almost all cases. So asking before certain destructive actions is still a good practice.
darkwater 3y ago
> Also frankly I think most software does it wrong, if it is possible it shouldn't ask before delete but just allow to undo the step easily. Obviously. When undoing is not easy or possible automatically, there is the "Are you really really sure?" dialog.

Aerroon 3y ago

>The paradox is that every device I use interrupts me non-stop with modal dialogs ad nauseam. Pop-up warnings that are too common are a problem itself. People get so used to accepting them immediately that they stop serving their purpose and just become an annoyance. With one exception: they can prevent misclicks.

davidthewatson 3y ago
Right! That's why I used the term alert fatigue: https://en.wikipedia.org/wiki/Alarm_fatigue https://en.wikipedia.org/wiki/Alarm_fatigue The misclick point is beyond truth, particularly given the storm of marketing that is mobile web.

taneliv 3y ago

In a company where we chose to do production SQL shenanigans in the spirit of "move fast, break things", I developed a habit of starting those with "BEGIN;" and paying careful attention to the number of records modified before calling it a "COMMIT;". In case of unexpected numbers, immediate "ROLLBACK;" so as to not hog the resources and make the applications suffer. Even fatigued, "DELETE 1182900" tends to stick out, if you're used to, and expecting to, see "DELETE 1". ("BEGIN" appears to be PostgreSQLism, "START TRANSACTION" is more standard.)