4 ms·

I want to preface this by saying that if this comes off as condescending that's not my intention. > Blameless post-mortems should be the industry standard. Su

by yladiz 10y ago

I want to preface this by saying that if this comes off as condescending that's not my intention. > Blameless post-mortems should be the industry standard. Sure, often times there are multiple reasons why something isn't accomplished, something is broken, or something doesn't work as intended. But generally there is someone that's primarily responsible for the piece of code, be it a manager, engineer, etc. It does suck to be on the receiving end of it and if it's major enough you can be out of a job, but blame should be given to the responsible party/parties and the issue should be handled appropriately as it's more direct than what alternatively happens which is to passive-aggesively handle the situation. Plus, how you handle crises like production going down and being blamed for it say just as much about you as an engineer as does your code. Essentially, I'm against being coddled as an adult. We're adults, someone fucked up and is responsible for it, they should be blamed and handle it, and handle it like an adult. I do think that handling that kind of situation as person on the giving end definitely requires tact, though.

jdavis703 10y ago
The problem is that post mortems then become politicized, which means the actual cause may not be exposed, rendering the whole exercise pointless. It's part of the reason the FAA has all kinds of safe guards around reporting aviation hazards, even if the person who reported them is to blame.
Goronmon 10y ago
But generally there is someone that's primarily responsible for the piece of code, be it a manager, engineer, etc. It does suck to be on the receiving end of it and if it's major enough you can be out of a job, but blame should be given to the responsible party/parties and the issue should be handled appropriately as it's more direct than what alternatively happens which is to passive-aggesively handle the situation. The problem is deciding what is the actual goal of a post-mortem. Is it to fix the problem (and prevent it from happening again)? Or is it to figure out who is the person most to blame so that they can be punished. Because, honestly, you can't have it both ways. Plus, who makes the final judgement as to the party to be blamed and based on what criteria? Is it QA for not catching the issue, is it the engineer for forgetting to remove some debug code, the tech arch for not properly ensuring there were systems in place to prevent it from occurring in production, the program manager for not pushing back on deadlines that were too aggressive, or the CEO for constantly pushing employees to prioritize revenue over product quality? Plus, how you handle crises like production going down and being blamed for it say just as much about you as an engineer as does your code. Or your willingness/ability to find a suitable scapegoat.

by yladiz 10y ago

jdavis703 10y ago

The problem is that post mortems then become politicized, which means the actual cause may not be exposed, rendering the whole exercise pointless. It's part of the reason the FAA has all kinds of safe guards around reporting aviation hazards, even if the person who reported them is to blame.

Goronmon 10y ago

But generally there is someone that's primarily responsible for the piece of code, be it a manager, engineer, etc. It does suck to be on the receiving end of it and if it's major enough you can be out of a job, but blame should be given to the responsible party/parties and the issue should be handled appropriately as it's more direct than what alternatively happens which is to passive-aggesively handle the situation. The problem is deciding what is the actual goal of a post-mortem. Is it to fix the problem (and prevent it from happening again)? Or is it to figure out who is the person most to blame so that they can be punished. Because, honestly, you can't have it both ways. Plus, who makes the final judgement as to the party to be blamed and based on what criteria? Is it QA for not catching the issue, is it the engineer for forgetting to remove some debug code, the tech arch for not properly ensuring there were systems in place to prevent it from occurring in production, the program manager for not pushing back on deadlines that were too aggressive, or the CEO for constantly pushing employees to prioritize revenue over product quality? Plus, how you handle crises like production going down and being blamed for it say just as much about you as an engineer as does your code. Or your willingness/ability to find a suitable scapegoat.