@harrysintonen@infosec.exchange Most of my career has been as the indispensable engineer in the IT department, making things work. One day I determined that the product engineers were shipping native code libraries for a Java project and had never bothered to use even thread-safe libraries.* They didn’t want to hear it from “the IT guy” so I went through their code, built it with the right libraries and calls and the “intermittent crashing problem”* went away. I cited the official Sun guide to native code libraries so this was a week-long exercise of RTFM to a team short on that deep platform knowledge of how things work. Junior coders masquerading as senior engineers. * Threads and other forms of concurrency can result in two different flows of execution using the same memory so unless steps are taken to mitigate it, an algorithm could assume the zero it stored would still be a zero when it came time to read it and depend on that fact unaware the other flow changed it to one. Java could be written as if it was a single flow of execution but it would, unasked, use just such a second flow of execution to clean up the memory allocated by the main program, so all code needed to be thread-safe. Many historical C libraries had routines which were unsafe because it was impossible to mitigate the risk described above. And “intermittent crashing” is precisely the type of problem that is caused by some unsafe code failing due to circumstances (threads concurrently using the same memory) more likely to happen in long production sessions under high loads that the developer desktop tests. They needed a minimum amount of platform knowledge for this product and their customers were right to complain until an IT manager asked me