It's about what broke, not who broke it

Post by commandlinefan » Wed, Mar 28, 2018, 2:25 PM UTC

_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…

Post by taco_emoji » Wed, Mar 28, 2018, 2:32 PM UTC

mieseratte wrote: post #74

silveroriole wrote: post #72

Earlier quoted context omitted.

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…

Two things: First, it's generally best to praise publicly, and criticize in private. Second, saying "@Users's commit screwed-the-pooch" blames but, frankly, may not be the whole picture. It's entirely possible that the commit caused the issue, but everything was done by the book in which case it's really an organizational failure. Personally, I sympathize with your argument. I have no personal problem with Torvald-st…

Post by andrewmcwatters » Wed, Mar 28, 2018, 2:34 PM UTC

ashleyn wrote: post #67

Reminds me of when someone ran "rm -rf /" at Pixar and deleted all of Toy Story 2. The backups were crap and the only reason it survived was because someone took a server to work from home. When all was said and done, they never really found who did it, they just made organisational changes to ensure it didn't happen again. No blame game.

Post by dozzie » Wed, Mar 28, 2018, 2:48 PM UTC

dfox wrote: post #78

dozzie wrote: post #57

Earlier quoted context omitted.

> [...] not all settings were applied until you opened the UI provided by the vendor. [...] the NICs would reboot, just long enough to kill TCP connections. The UI part suggests that it was Windows, and if it was, it's not quite the case that "just long enough" to kill TCP connections, as you need quite a lot of downtime to terminate a typical TCP session. In Windows, if a NIC goes down, all the TCP connections that…

Windows is often the only vendor-supported choice for interfacing your computer applications to PLCs and such things. Also most of the proprietary protocols run over industrial ethernet are some kind of legacy serial (232, 485..) bytestream format wrapped in TCP and the software usually does not handle loss of the TCP connection particularly gracefully. (on multiple occasions I've seen rules like "reboot the whole in…

Post by lkrubner » Wed, Mar 28, 2018, 2:58 PM UTC

itronitron wrote: post #33

lkrubner wrote: post #30

There is the risk of conflating two separate types of problem. There are problems that arise from the complexity of the code, and problems that arise from particular people. If a programmer has a habit of sloppy code, or violates the team's standards in some ways, then a good leader will keep track of the fact that one person is responsible for a recurring pattern of mistakes. I absolutely agree with Rachel By The Ba…

if the function was still there, I think it is also likely that the old jar or class file (with the function) was still lurking in the classpath or your version control and build system weren't using his revision