1,940 karma · joined August 23, 2007
afton-hn@howtoprocrastinate.com
I've been fighting this fight for a decade now, and I'm pretty sure I've never won it for a whole team. The best I got was that people would pre-populate bug fix code reviews with reasons why they couldn't sensibly unit test this particular issue. If you have had better success, please tell me your secrets!
I'm just saying that I would 100% not do this unless I had no other choice, or was independently wealthy.
This isn't to say that those people don't add value, but if they do this for a few years, they may find that their ability to do greenfield coding has significantly diminished, so much so that they struggle to write objectively simple code because they've fallen out of practice.
Source: I've been one of those people, and I've worked with many. It's an easy rut to fall into, particularly in Test Engineer role (what MS used to call SDET roles).
If I'm sitting on 2 offers, one is a hire and one is a "Let's see how this works out after 2 weeks of work", I'm going to take the first one. And that says nothing for the necessary benefits question in the states, where changing jobs often involves expensive (in money or time) changes to health care insurance.
This adds nothing to the discussion.
> Your belongings and wealth belong to your estate and as the owner of it you decide how it should be distributed.
Well, that's literally the question at hand. You don't get to just say that it is so. A dead person's wealth belonged to them, but they are dead. They can't vote, they can't apply for loans, and, the parent is arguing, they can't arbitrarily pass their money to whoever they choose. They could have, while alive, but now they are dead.
> Because it's none of your business. Why on earth are you vilifying people for wanting to pass down their hard-earned money to their children?
This is just some weird non-sequitur. No one's doing any vilifying, and Parent is arguing that it is societies business (and incidentally, given that an estate tax exists, society currently agrees with the parent poster)
Methods We did a randomised, double-blind, placebo-controlled, multicentre trial at ten hospitals in Hubei, China. Eligible patients were adults (aged ≥18 years) admitted to hospital with laboratory-confirmed SARS-CoV-2 infection, with an interval from symptom onset to enrolment of 12 days or less, oxygen saturation of 94% or less on room air or a ratio of arterial oxygen partial pressure to fractional inspired oxygen of 300 mm Hg or less, and radiologically confirmed pneumonia. Patients were randomly assigned in a 2:1 ratio to intravenous remdesivir (200 mg on day 1 followed by 100 mg on days 2–10 in single daily infusions) or the same volume of placebo infusions for 10 days. Patients were permitted concomitant use of lopinavir–ritonavir, interferons, and corticosteroids. The primary endpoint was time to clinical improvement up to day 28, defined as the time (in days) from randomisation to the point of a decline of two levels on a six-point ordinal scale of clinical status (from 1=discharged to 6=death) or discharged alive from hospital, whichever came first. Primary analysis was done in the intention-to-treat (ITT) population and safety analysis was done in all patients who started their assigned treatment. This trial is registered with ClinicalTrials.gov, NCT04257656.
Findings Between Feb 6, 2020, and March 12, 2020, 237 patients were enrolled and randomly assigned to a treatment group (158 to remdesivir and 79 to placebo); one patient in the placebo group who withdrew after randomisation was not included in the ITT population. Remdesivir use was not associated with a difference in time to clinical improvement (hazard ratio 1·23 [95% CI 0·87–1·75]). Although not statistically significant, patients receiving remdesivir had a numerically faster time to clinical improvement than those receiving placebo among patients with symptom duration of 10 days or less (hazard ratio 1·52 [0·95–2·43]). Adverse events were reported in 102 (66%) of 155 remdesivir recipients versus 50 (64%) of 78 placebo recipients. Remdesivir was stopped early because of adverse events in 18 (12%) patients versus four (5%) patients who stopped placebo early.
Interpretation In this study of adult patients admitted to hospital for severe COVID-19, remdesivir was not associated with statistically significant clinical benefits. However, the numerical reduction in time to clinical improvement in those treated earlier requires confirmation in larger studies. Funding Chinese Academy of Medical Sciences Emergency Project of COVID-19, National Key Research and Development Program of China, the Beijing Science and Technology Project.
While lots of people 'know old people' or with pre-existing conditions, many people have youngish parent with already passed grandparents, who have trouble understanding why this is a fuss for them, since they imagine that it'll just be a cold (for them). Cases like this one are 'scary' because it shows that they might still be at risk. Which, in some sense, is good if it makes 'normal people' scared enough to actually stay home/self-quarantine.
I really don't think this has anything to do with the "US-centric mindset of blaming people for their own [snipped]".
Anyway, since you seem to be doubling down on being an asshole, I don't intend to reply again here.
If you have constructive criticism, this is the right place for it, but frankly, you're just being mean on the internet for no reason.
There is a cost to a brittle test. UI testing suffers from this more than other kinds because there are many 'plausible' UI arrangements, and as the product shifts and changes, you need to distinguish
1. "The dialog moved slightly to the left"/"We refactored the HTML, but it still looks the same" from
2. "The dialog is now underneath another element".
Suppose it takes 10 minutes to find, fix, get reviewed, and push the fix, deploy the fix, and validate the fix. If the number of failures that are more like the former are RADICALLY more than the latter type of failure, then it is easy enough to come to the conclusion that the test is not giving you a reasonable ROI. Perhaps the cost of releasing a latter-type-of-failure is not that bad, if you can fix it and get it to production quickly. It might be cheaper overall then the ongoing maintenance cost on a test that would prevent this failure.
Also, and this is culture and product dependent, but we're talking about this like it's a single test, when it's usually a suite of tests (or multiple suites). If they have a 5% failure rate, and 95% of the time its really an 'update the test, this is the new expected', people will stop trusting the tests, and will take shortcuts. So you may find that instead of spending 100% of the maintenance costs for the suite of brittle tests, you're spending 70%, but only getting 20% of the benefit because people become accustomed to the failures , and once a test is failing, no one will notice that the failure changed from a 'benign failure' to a "customer-can't use" failure. (Note: numbers are imaginary, but not crazy).
At one company I worked for, it was so bad, that when we tried to introduce testing/checkin rigor, multiple developers pulled me over to make me explain "Why this dumb test is failing on my checkin attempt", and we would look at the logs and other artifacts to uncover that "It's failing because you changed something without updating the relevant tests". It took quite a bit of time to re-train developers used to brittle tests, to respect and maintain non-brittle ones.
And that is why I am against automated UI testing in general. :)
I don't know what specific problems you were having, so I can't give more specific advice than that.
My two cents: I've never seen automated visual regression testing that wasn't terrible to work with, and where the most common result (by a large margin) of a test failing was someone would update the expected file/image so it would pass with the new visuals. It's a hard problem, and one that I've personally decided isn't worth doing for the customer facing software that I've been involved with.
Straight up running red lights or stop signs does seem like it is overrepresented by cyclists, but I really don't they they're overrepresented for generic 'breaking the law'.
I wish more people would give real, actionable feedback on interviews.
Hah. I injured my hand a couple of years ago, and had to type with one hand for a couple of months. I could code review, I could participate in meetings, I could identify the source of a bug. But I could not write any but the simplest code. I was mystified. I could write emails and to some extent documents (typing of course slowed down a lot). But I became basically incapable of writing code. Using too much brain power on the physical act makes you have less left over for the CONTENT. Cool to see that this problem was understood much earlier.
As for the rest, it's hard to know what to make of it. It's like you're building a superpower out of failure to be able to focus when it's necessary to focus. Like if someone couldn't stand still, and you said something like "I bet it's really useful, because you never get stiff, and you burn more calories", but ignoring that it's fucking terrible, because you can't ever sit still even when it would be advantageous to sit still.
Note that executive control is also about planning. Of course it can be useful to rush of without planning, like when being chased by a panther. But it's not a good idea to have a significant deficit in the ability to plan. "Silly bullshit [that] doesn't matter" can mean not having the ability to pay for food, and it can mean having terrible stress over accomplishing trivial tasks (like filing out tax paperwork!).
Anyway. You're welcome to continue to not-buy ADHD, but recognize that people who live with, and who study it, think it's a thing.