3 ms·

we might be moving the state of the art forward faster than they might in structural engineering simply because we have the freedom to fuck around and learn Th

we might be moving the state of the art forward faster than they might in structural engineering simply because we have the freedom to fuck around and learn Thanks-- I think that's a very concise response & reflection on my comment. I still think we can & should do better, but you're right that the lower stakes probably lower the bar on acceptable crystallization of experience into best practices. Which is problematic because of things like writing a library for your own low-stakes project, but the library gets published on github and used by someone in a something that isn't low stakes. Maybe part of what we need are defined "stakes" levels and corresponding criteria for acceptable practices at each stage.

SmellTheGlove 5y ago
> I still think we can & should do better Totally! And I really like > Maybe part of what we need are defined "stakes" levels and corresponding criteria for acceptable practices at each stage. I think I'm going to start testing this with the TPMs and Engineers I work with. I'm going to ask a more senior TPM on my team to think about this and how it should be incorporated into our specs. My hypothesis is our engineers would be happier knowing about the risk profile of whatever failure modes we've id'ed, and they can design accordingly. That said, I don't really work on high risk software, so this is all relative. Most of our stuff is in the "push the button again" category if it dies.