3 ms·

Yeah, if the difference between the command to do something safe and the command to do something dangerous is 1 character or whatnot, you can't blame someone wh

Yeah, if the difference between the command to do something safe and the command to do something dangerous is 1 character or whatnot, you can't blame someone when they screw up and fat finger the dangerous one. Most of the tools I write require explicit --nodryrun if they're doing something dangerous or irreversible, and beyond that the really scary ones require some kind of acknowledgement that "THIS WILL TURN 1073 MACHINES OFF, ARE YOU CERTAIN, TYPE 1073 TO CONFIRM YOU WANT TO DISABLE 1073 MACHINES."

darkerside 5y ago
I would 1000% expect a principal engineer to know the difference between a safe and unsafe process and refuse to engage in an unsafe one without many redundant safety checks. It's the principal engineer's job to make the unsafe process safe, is it not?
- joshuamorton 5y ago
  Ah yes, just magically know that the command in the playbook isn't safe and refuse to use it during an incident. I want to meet your principal engineers who can fully understand a command's complete set of side effects solely from a bash snippet telling you how to invoke it! Like yes, it is the principal's (well really everyone's, but sure insofar as someone is ultimately responsible, we can make the principal engineer responsible) responsibility to ensure processes are safe. But you can't do that by magically "refusing to engage in an unsafe process". Because it's difficult to know a priori if a process is inherently unsafe. Usually you figure this out when something goes wrong, and then you take that learning from a postmortem/incident report and try to apply it to other similar tools. But no, I wouldn't blame anyone, not even a principal engineer whose job it is to ensure safe systems for accidentally fat fingering a dangerous command that they didn't know about. They perhaps bear some responsibility for not having previously fixed it, but they bear approximately none for misusing a tool that makes itself easy to misuse.

darkerside 5y ago

I would 1000% expect a principal engineer to know the difference between a safe and unsafe process and refuse to engage in an unsafe one without many redundant safety checks. It's the principal engineer's job to make the unsafe process safe, is it not?

joshuamorton 5y ago
Ah yes, just magically know that the command in the playbook isn't safe and refuse to use it during an incident. I want to meet your principal engineers who can fully understand a command's complete set of side effects solely from a bash snippet telling you how to invoke it! Like yes, it is the principal's (well really everyone's, but sure insofar as someone is ultimately responsible, we can make the principal engineer responsible) responsibility to ensure processes are safe. But you can't do that by magically "refusing to engage in an unsafe process". Because it's difficult to know a priori if a process is inherently unsafe. Usually you figure this out when something goes wrong, and then you take that learning from a postmortem/incident report and try to apply it to other similar tools. But no, I wouldn't blame anyone, not even a principal engineer whose job it is to ensure safe systems for accidentally fat fingering a dangerous command that they didn't know about. They perhaps bear some responsibility for not having previously fixed it, but they bear approximately none for misusing a tool that makes itself easy to misuse.