3 ms·

To add to this - if there's a pattern of having to take part blame/ownership for people who should know better I'm going to move on to greener pastures. Some p

To add to this - if there's a pattern of having to take part blame/ownership for people who should know better I'm going to move on to greener pastures. Some people work more carefully than others. This is absolutely a thing in software development/operations (my fields). When I was young, I had more screw-ups because I was still learning "how to work carefully" with certain things... It's hard for me to admit this but it is 100% the truth. When things went wrong, I felt the need to take it on my shoulders vs. to put it on the rest of the team who likely had nothing to do with the error. As with all things this isn't black and white, which is why I'm making this comment.

underwater 7y ago
I want to minimise the number of times that a single person "being careful" is the difference between a smooth experience and an extended service outage. I also favour responding to mistakes quickly over preventing them completely. I've seen a lot of teams where there was the one keeper of the systems who knew how to do all the deployments and migrations. In every situation they became a bottleneck for the team, and prevented any real improvements being made.
- folkhack 7y ago
  In my experience you literally can't idiot-proof ops. In every operational role I've ever been in there's still very trusted people hammering out commands with very privileged accounts. Even at my last role people would get angry at me when I'd ask for "command confirmation" and/or "an extra sets of eyes". In my world, I favor getting it right vs. responding to mistakes. It's the difference between "scalable" and "firefighting". Having a SPF asset who holds the keys to the entire kingdom is a completely different problem, and a different conversation.
lonelappde 7y ago
If you keep making mistakes that get caught in testing, you need to be careful. If you keep making mistakes that get caught in production, you need to write better tests.
- folkhack 7y ago
  > If you keep making mistakes that get caught in testing Ha, yea. I can get behind this. There are times that one dumb thing causes the entirety of my tests to crumble and I'm always admittedly laughing saying "that's why we have tests!"

underwater 7y ago

I want to minimise the number of times that a single person "being careful" is the difference between a smooth experience and an extended service outage. I also favour responding to mistakes quickly over preventing them completely. I've seen a lot of teams where there was the one keeper of the systems who knew how to do all the deployments and migrations. In every situation they became a bottleneck for the team, and prevented any real improvements being made.

folkhack 7y ago
In my experience you literally can't idiot-proof ops. In every operational role I've ever been in there's still very trusted people hammering out commands with very privileged accounts. Even at my last role people would get angry at me when I'd ask for "command confirmation" and/or "an extra sets of eyes". In my world, I favor getting it right vs. responding to mistakes. It's the difference between "scalable" and "firefighting". Having a SPF asset who holds the keys to the entire kingdom is a completely different problem, and a different conversation.

lonelappde 7y ago

If you keep making mistakes that get caught in testing, you need to be careful. If you keep making mistakes that get caught in production, you need to write better tests.

folkhack 7y ago
> If you keep making mistakes that get caught in testing Ha, yea. I can get behind this. There are times that one dumb thing causes the entirety of my tests to crumble and I'm always admittedly laughing saying "that's why we have tests!"