Post #1928612

2026-04-22 13:12 UTC

@rupdecat Speaking as a non-academic, I had a supervisor come into my office and literally shout at me for 10 minutes to the extent that one of our secretaries cracked my office door open to see if I was okay. I reported him to what passed for HR at my firm, not so much for my benefit but for others (use one's older white male privilege for good). The company's main businesses were nuclear safety, runaway chemical reaction research (chemical safety), and combustability testing (fire safety). I mention this because at the time, I was running an experiment on natural circulation of hydrogen and air for nuclear waste package design (we always worry about hydrogen explosions; Fukushima showed why.) I am not an experimentalist, I didn't design the experiment, and in retrospect I am very lucky I did not literally blow myself up. A chilled work environment is corrosive to safety culture; that is well known among regulators, safety professionals, and the nuclear industry at large. It's right there under "Respectful Work Environment" in INPO 12-012 "Traits of a Healthy Nuclear Safety Culture" https://www.nrc.gov/docs/ML1303/ML13031A707.pdf Nobody should have to suffer abuse to get their job done in academia, industry, or anywhere. Academia's hierarchy and inherent competitiveness make it especially difficult for younger more vulnerable researchers to report abusive behavior. I had a lot less to lose than most and it was still difficult to come forward. But it had to be done. If you have the time, read through the link above; it's short and aside from the few nuclear-specific parts it's generally applicable. It should be especially valuable for researchers working with hazardous experiments.

Replies (1)

@arclight@oldbytes.space 2026-04-22 13:51

@rupdecat On a happier note, I'm working somewhere else in possibly the best environment I've ever been in doing work that I love. Even the awful parts like trying to modify research-grade R code to run in a controlled production environment under a strict software QA program. You don't really see the value of modern C++ and Fortran code until you try building and deploying R or Python code in this sort of HPC environment. Having a single statically-linked executable file simplifies so much - no complexity of containers, no dependency pinning, no interpreters changing every few months. As a bonus, compiled codes are fast. Performance is the least of my concerns; making sure our engineering tools are dependable, easy to run, and qualifed for safety use is my main goal. So many of these tools originate in academic environments where industrial-grade software QA is basically unknown. Everyone gets a very rude surprise when research-grade code finds its way into safery-related industrial use. Problems would be mostly avoidable if there was a good way to communicate industrial requirements and practice back to labs, RSE is a good step toward that but in the end, research orgs don't work under the same standards and regulation and incentive structure as we do and it's not clear if better communication would make any difference. Software QA suffers from problem that its benefits are invisible - nobody sees the papers not retracted, the accidents that didn't happen, the work avoided because the code was dependable and trustworthy.

Open ##1928613