It's about what broke, not who broke it • Hacker News Board

Re: It's about what broke, not who broke it

#101

Post by MR4D » Wed, Mar 28, 2018, 7:29 PM UTC

commandlinefan wrote: post #81

_n_b_ wrote: post #53

I work in the nuclear industry, where most places are pretty good about maintaining a "blame-free" culture. You focus on what processes and procedures failed, what controls were missing, etc., that allowed somebody to make a mistake. As this attitude was adopted, things shifted too far (at least in the opinion of industry groups, and my observation) to the point where people underperforming to the point of negligence…

> where people underperforming to the point of negligence Well (to play devil's advocate just a bit) - isn't the ultimate end-goal of an end-state robust process one in which people can not just underperform, but be replaced completely?

Only if the technology exists to do so.

Given the above discussion about a nuke plant, think of all the complexity inside it: - monitors - alerts & triggers - valves - compressors and other rotating equipment - fire safety - electrical systems

All of those have to be checked, tested, maintained, and fixed on a periodic basis over their lifetimes.

An incompetent person (or group) will eventually be the cause of something.

Maybe 100 years in the future we'll have self-operating nuke plants, but doubtful in my lifetime because of the incredible scale of complexity.

Re: It's about what broke, not who broke it

#102

Post by pnathan » Wed, Mar 28, 2018, 7:55 PM UTC

jerrre wrote: post #54

pnathan wrote: post #26

Earlier quoted context omitted.

Most mistakes aren't problematic. But while we blame the code, not the writer - it serves well to quietly have a counter of "problematic errors" and to keep an eye on the people who increment it the most. After a while, and after a pattern has been established...

You could also have a counter of problematic area's: some parts are easier to break than others, and could be improved/made more robust...

> You could also have a counter of problematic area's: some parts are easier to break than others, and could be improved/made more robust...

Oh yes. Nothing I said should be read as precluding that. High-risk components cause more fallout when they break, that's how it works. Or fragile components break easily. Sure.

But it's wise to keep an eye out for people who are seriously problematic and to establish a pattern of problem-causing, for the purposes of remanding to HR.

Re: It's about what broke, not who broke it

#103

Post by badminton1 » Wed, Mar 28, 2018, 9:50 PM UTC

badminton1 wrote: post #15

If in soccer the opposing team scores, who is to blame? the goalkeeper, defenses? the coach? the whole team? the referee? nobody? Preventing goals means that the strategy needs to ensure good ball possession, and staying on the offense, to reduce the burden on the defense, to reduce the burden on the goalkeeper, who is the last line of defense. If the last line of defense fails that's not an individual failure but a…

Now, there are cases when everyone knows what to do, steps are taken so everyone is informed of it, but someone still decides to go against it. In that case the individual is at fault.

Re: It's about what broke, not who broke it

#104

Post by uoaei » Thu, Mar 29, 2018, 1:59 PM UTC

CoolGuySteve wrote: post #3

I used to think this way until I started working with someone who was nearly always the one who broke it. At some point we just had to face the fact that his work was unreliable even after significant mentoring. If the tasks were difficult that would be one thing, but I'm talking about stuff like committing code to prod that was clearly never even executed once.

In that case, the "what broke" was the hiring process and the fix is them leaving that role.

Re: It's about what broke, not who broke it

#105

Post by foobarchu » Thu, Mar 29, 2018, 6:44 PM UTC

silveroriole wrote: post #72

ComputerGuru wrote: post #69

I do a lot of open source work and unfortunately a very common posion is focusing on “who broke it,” which is especially disparaging when done in public. A particularly nasty habit is when outsider Alice opens an GitHub issue saying “xxxx is broken” and developer Bob replies with “yup, @Charlie’s commit fubar’d everything.” Unfortunately both very demoralizing and very common.

Demoralizing - why? That seems like an attitude problem on the part of “Charlie”, not “Bob”. If “Charlie” is going to slink off with his tail between his legs every time he makes a mistake, he’ll have a tough time of it - it’s not like everyone can’t SEE that he broke it through version control anyway! I just don’t really get it. Even when I was a junior, if I overheard “this thing is broken,” I was the first to pop…

I think its demoralizing because it's active blaming. Charlie doesn't have an attitude problem just because he doesn't like being publicly blamed for something, Bob has an attitude problem because piling it on somebody else is his first reaction.

The proper thing here is to acknowledge that there is an issue, but not assign blame. Go to the person you think is responsible in private, and let them admit the mistake in public if they want. Assigning them blame publicly shows a huge lack of respect, even if it was their fault, while admitting blame freely shows modesty.

Plus, what if it's not Charlie's fault, and his commit simply revealed the problem? Perhaps the actual issue is in a little used function deep down in the codebase, and his commit is just the first one to actually exercise that area the right way? Maybe this whole thing comes around to being Jim's fault instead.