This sounds depressing. I’m sorry that you had that experience.
It’s a frustrating position to be in, and you can feel quite helpless.
In my experience, it’s less about “do only what’s asked”, and rather “say no”.
I.e. explain “I can do X, but if I do that then Y will suffer, and Y is a priority”. (Y being another company priority, or even your own mental health). Stated in these terms, it’s easier to negotiate your time with your coworkers.
I did this but I was surrounded by coworkers who were stupidly running straight into burnout themselves and said yes to anything.
Well, upper management felt I wasn’t doing enough in comparison and pressured/harassed me. Ultimately, I were the first to burn out.
Of course, in hindsight, I should have left way before it happened, but when you are in, you have no hindsight. Sometimes you can’t grab the surrounding toxicity before being hurt.
FWIW, I don't think the code style in [2] is less simple (slightly more readable, to use `if (X) {} else {}` rather than `if (!X) {} else {}`, for example).
So to me, this reads as the author of [1] is just overcorrecting by adding process, when some test cases or code review would've been more helpful in preventing whatever incident [2] caused.
Not only that, real users actually want to use the service, not overload it. A real user might only make one request a second. A botnet device is trying to make a thousand requests per second to overload the server. Even if they each have the same CPU as a normal user, now each node in the botnet can only make as many requests per second as a user or the user can outbid them.
Exactly. I know if medication were to be developed, checking "are GDF15 levels significantly lowered" would be part of the trials.
But how often does the medication development process check the result we care about: "does this medication then go on to reduce the chance of dementia?"
> Posting a Wikipedia link without commentary or context is essentially a text meme. It doesn’t invite discussion.
You literally just replied and we are engaging discussion — empirically the wiki link above has done literally the opposite of what you are saying! At any rate, the intended relevance of the wiki link regarding loss aversion is the following:
When something bad happens to someone, they tend to overestimate how bad it is relative to something experienced as objectively equally good; it is thus important to be aware of such a bias — in addition to using regular old critical thinking.
In this case, critical thinking could look like the following: “although this is a ‘migration’, what do we mean when we say that? and is it really the same thing as py2 to py3?”
I would tentatively propose “no” to the latter question; and would additionally propose that calling this a “migration” is not terribly useful as although it’s not incorrect, it’s insufficiently specific and seems to invite a category error.
In addition to the loss aversion bias mentioned above.
> How would you alternatively design a system that calls emergency services in a crash?
If you want to prevent false positives—then, same as you’ve described, but only enable when either:
- phone is connected to Carplay via USB or bluetooth
- phone is connected to a bluetooth device known to be an auto (inferred by manufacturer ID, and configurable in bluetooth settings)
- GPS data for the last 5 minutes indicate you’re driving
And display an indicator on lockscreen that shows this feature is enabled.
Of course, consider that the downside of false positives don’t affect consumers or manufacturers—rather, they affect public utilities. Then, it’s easy to understand why this happens.
It’s a frustrating position to be in, and you can feel quite helpless.
In my experience, it’s less about “do only what’s asked”, and rather “say no”.
I.e. explain “I can do X, but if I do that then Y will suffer, and Y is a priority”. (Y being another company priority, or even your own mental health). Stated in these terms, it’s easier to negotiate your time with your coworkers.