Earlier quoted context omitted.
But now you have someone in your team who will never, ever make that same mistake again and should be your new go-to guy for all X related changes (X being DNS or what-have-you). Firing someone with that type of experience does not lead to success. 100% of all devs make huge mistakes, at least once.
> But now you have someone in your team who will never, ever make that same mistake again and that should be your new go-to guy for all DNS related changes. I'm not entirely sure that's always true. For example, i've seen people introduce N+1 issues into a codebase, spend evenings fixing them and refactoring code to fix production issues... just to later introduce those very same types of issues. Sure, you can learn…
>> a quality gate
Yes, this, also.