4 ms·

The fault here does not lie with just one person. One person ran the rm -rf command. Other people failed to check the backups. Others made the decision to give

by weavie 10y ago

The fault here does not lie with just one person. One person ran the rm -rf command. Other people failed to check the backups. Others made the decision to give everyone full root access. Really it was a large part of the company that was to blame.

StavrosK 10y ago
Whenever there's a bug in code I reviewed, there are at least two people responsible: The person who wrote the code and me, the person who reviewed it. I've found that that helps morale, as there's a sense of shared responsibility, but there's no blaming people for problems where I work, so I haven't actually seen what happens when people are searching for the culprit. The usual process is "this happened because of this, this and this all went wrong to cause us to not notice the problem, and we've added this to make it less likely that it will happen again". If you have smart, experienced people and you get problems, it's because of your processes, not the people, so the former is what you should fix.
- mulmen 10y ago
  Everywhere I have worked took the shared responsibility approach, I think that's the status quo but there are obviously exceptions. One day at $megacorp a bug caused a production outage and a project manager sent an email to the team calling out the engineer who committed the change and asking us all to be more careful in the future. That manager was immediately reprimanded both in the email chain and in private. I find the culture of shared responsibility to be one of the best qualities of our industry, even if it isn't universal.
orbitingpluto 10y ago
Oh god. I know someone who made all of these mistakes by themselves in a certain week. And kept his job. He was pretty. I left and found out two months later from a friend he had managed to take down almost every single server in the place for which he had access. Even the legacy don't touch systems that just boot and run equipment. Be pretty.

by weavie 10y ago

StavrosK 10y ago

Whenever there's a bug in code I reviewed, there are at least two people responsible: The person who wrote the code and me, the person who reviewed it. I've found that that helps morale, as there's a sense of shared responsibility, but there's no blaming people for problems where I work, so I haven't actually seen what happens when people are searching for the culprit. The usual process is "this happened because of this, this and this all went wrong to cause us to not notice the problem, and we've added this to make it less likely that it will happen again". If you have smart, experienced people and you get problems, it's because of your processes, not the people, so the former is what you should fix.

mulmen 10y ago
Everywhere I have worked took the shared responsibility approach, I think that's the status quo but there are obviously exceptions. One day at $megacorp a bug caused a production outage and a project manager sent an email to the team calling out the engineer who committed the change and asking us all to be more careful in the future. That manager was immediately reprimanded both in the email chain and in private. I find the culture of shared responsibility to be one of the best qualities of our industry, even if it isn't universal.

orbitingpluto 10y ago

Oh god. I know someone who made all of these mistakes by themselves in a certain week. And kept his job. He was pretty. I left and found out two months later from a friend he had managed to take down almost every single server in the place for which he had access. Even the legacy don't touch systems that just boot and run equipment. Be pretty.