3 ms·

What happened to you is clearly not your fault, but after having similar issues with big institutions, I've realized that doing more than one "important" operat

What happened to you is clearly not your fault, but after having similar issues with big institutions, I've realized that doing more than one "important" operation on a " big business/bank" account is always finicky. So now I do things one at a time. E.g. To cancel a card, first move all money (or debts) from acct A to acct B. Go home. Couple of days later, pay any outstanding fees of acct A. Go home. Couple of days later, request cancellation. Inevitably find that something else needs to be done, so do that thing. Go home. Couple of days later.... You get the idea. It sucks big time, but I've found it's better that way, since the probability of error is somewhat lower (and even then it happens!)

cipheredStones 5y ago
It's sort of funny that software engineers spend so much time thinking about the nuances of making sure that things occur in the right order on the scale of milliseconds while maintaining invariants in all sorts of exotic distributed NoSQL systems that don't guarantee strong consistency... and meanwhile many of the most important things we do on computers use standard centralized relational DBs but take several business days to process and get screwed up if you don't wait long enough for them to resolve properly.
xtiansimon 5y ago
I’m starting to adopt a similar idea about non-urgent healthcare. I have found healthcare providers can not communicate costs when they have more than one procedure.