> young adults with 0 professional experience will probably not consider security & rely on the defaults of whatever stack they're using to be good enough. I t

> young adults with 0 professional experience will probably not consider security & rely on the defaults of whatever stack they're using to be good enough. I typed up a response with a few of my experiences, but it's probably wiser to not share those anecdotes at this time. Suffice to say I've had the exact opposite experience, where the only people who cared about security and stability in any capacity were the youngins, and the veterans dismissed any and all suggestions for improvement regardless of how diplomatically (or not) they were worded. The one anecdote I do feel comfortable sharing is in regards to stability, not security, but it's fairly similar to what I've encountered security-wise. Once, I inherited a legacy codebase very tightly coupled to a legacy platform. I managed to shove an abstraction layer in there, which was then used to port the same codebase between three very different platforms. The biggest problem that I had was in maintaining the very specific, somewhat unintuitive, completely undocumented behavior of the original codebase. Which was of course very tightly coupled to by downstream processes. But after getting the API in there, I was able to run the code on its own and that meant that I could start writing automated tests. I listed off the biggest pain points whenever changes were made and the most critical behaviors that actually generated revenue, and put them all under test. Everything that commonly went wrong (and there was a lot thanks to some unreliable domain-specific tooling) was now automatically validated whenever changes were made. When I showed one of my bosses (the owner of the company and someone in a former technical role) he was less than impressed. I was told off for avoiding my job, and instructed to test it manually like a real programmer.