Earlier quoted context omitted.
> a simple thing that the handbook doesn't talk much about is "when to quit", let alone when and how to engage in concerted action with other team members, and what the risks/benefits of that are. That may be because often trotted out as a convenient solution to any sort of wrongdoing by a lot of privileged people who themselves have their pick of jobs in US companies. It's a convenient null hypothesis that could be…
I can't resist this bikeshed, but you've written the Maximum Hacker News aside of the week. I have several car factory service manuals. They do not include cost benefit analyses on when to remove a vehicle from service. Instead, they are full of flow charts on how to diagnose problems. Each flow chart ends with a "If nothing failed a test, but the symptom persists, replace the entire part/assembly." The goal is to pi…
> Each flow chart ends with a "If nothing failed a test, but the symptom persists, replace the entire part/assembly."
I suppose this kind of does refute my point a little bit. Maybe the Tech Worker Handbook should have rules of thumb on when to quit – e.g. if the estimate for legal fees is going to be more than 1% of your salary, evaluate if makes more financial sense to quit your job and look for a new one instead.
Of course, circumstances differ wildly between individuals, so anything more than a rule of thumb is not possible.