* a contained smokey fire is sufficient to hide the start of a wildfire
This means:
* keep your errors at 0. If it "can't be kept at 0" you're either too far gone or thinking about the issue incorrectly.
* user complaints are errors. Just because they aren't clear doesn't make them any less so.
There is a perception that users go out of their way to make unfounded complaints. In my experience, getting any complaints is the issue.
There is also a perception that some errors aren't important. If you have a channel to recieve an error its because it has business value. If a dev I was managing ignored a p/w entry bug due to non-dupe / assumed user error without significant digging and user interaction I'd be livid. Most businesses will lose significant value if users perceive the act of logging in as difficult.
keeping errors at zero does not mean errors don't happen, it just means you resolve them all, you don't ignore any. Perhaps it should be 'keep errors at 0 or 1'.
So if you're small, a RAM issue is something you deal with manually and rarely. As you get bigger you'll transition to automated failovers that still get looked at individually. Then you'll scale up to the point where these aren't freak occurrences. Now its important for you to have a strategy to identify the issue and its follow on issues, and resolve them. Its also past time you think deeply enough about your setup to be able to contain them so you can stop surfacing them as errors - they are now part of a normal business process. You want to make sure that too many are surfaced as an error (and too few), and any effects you can't currently recover from automatically are also errors.
Its perfectly possible to "keep errors at 0" without ignoring any output.
I agree with you on most parts, but not about keeping your errors at zero. In a fast moving environment, there will be mistakes or things that are missed. ideally, bugs should not have any attached meaning - yes there was an issue and now it is fixed. Good thing we found it today compared to a few days later. That is it.
Getting complaints from users is a good thing, but yeah missing them or not fixing them when you come across them is. As a user, I would be overjoyed if I reported a small issue, and the company fixed it quickly.
Being livid is natural, but I was pretty sure the developer himself knew he screwed up this time, so no point expressing it. Plus as I explained in the earlier comment, this escaped for so long because we did not have many cross device users. So did not affect that many users. Just for my experience, I check this every single time i test a website before it goes live. (and also check with other keyboards than just Gboard)
* smoke means fire
* a contained smokey fire is sufficient to hide the start of a wildfire
This means:
* keep your errors at 0. If it "can't be kept at 0" you're either too far gone or thinking about the issue incorrectly.
* user complaints are errors. Just because they aren't clear doesn't make them any less so.
There is a perception that users go out of their way to make unfounded complaints. In my experience, getting any complaints is the issue.
There is also a perception that some errors aren't important. If you have a channel to recieve an error its because it has business value. If a dev I was managing ignored a p/w entry bug due to non-dupe / assumed user error without significant digging and user interaction I'd be livid. Most businesses will lose significant value if users perceive the act of logging in as difficult.