3 ms·

^ this is exactly the attitude I'm referring to. Let me give you an anecdote to further illustrate. Last friday my internet went out (Cox) and I called into s

^ this is exactly the attitude I'm referring to. Let me give you an anecdote to further illustrate. Last friday my internet went out (Cox) and I called into support. The first thing the guy told me? My equipment is too old. This is simply unacceptable as a reason why my internet stopped working at 6 in the morning. I suspect it was an attempt to upsell me a new modem, but I have a docsys 3 that's under 5 years old. It doesn't matter. Any series of events that results in technical support leading with blaming "old equipment" on the outage is wrong, period. Maybe the equipment went bad, it happens, but that's not what you lead with. Certainly not before trouble shooting. This is what I mean when I say "definitionally". It doesn't matter what their motivation is. It doesn't matter if it's possible that my equipment died. That employee fucked up. This isn't about technical excellence or software practices. This is about decision making.

aflag 6y ago
I'm not sure if that employee fucked up. That may be company policy. Support people usually follow a script and they very rarely venture much beyond that. Partially because they lack technical knowledge and partially because it could actually get them in trouble. If I understand it correctly and you were calling your ISP at 6am, I don't think the person you were talking to was a developer. That said, I have no expertise in customer relations, so I wouldn't know if they were following good practices or not in that instance. I get your point that people make bad decisions, but in software development, those bad decisions shouldn't break the user experience, but decrease the developer's (and/or the team's) productivity instead. Doing root cause analysis is part of the process to achieve that, as it can give insight on how to avoid that class of problems in future. That said, if someone is not doing a good job, they'd hopefully figure it out by themselves, but constructive feedback can also go a long way. Ultimately, if you have a good process in place, it should help you to make an educated assessment of who is underperforming (eg.: their PRs take very long to merge, they are full of beginner's mistakes, their code is never properly tested, their releases are always rolled back a few times until they get it right, etc). All of that without playing the blame game on the (hopefully) rare ocasion that a major bug is found in production.
- RandoHolmes 6y ago
  This is probably going to come across rude, but I feel like it needs to be said. nothing in your post was really relevant to this discussion. The fact that it may have been a company policy or that the person wasn't a developer is completely irrelevant to the larger idea. It's literally missing the forest for the trees. I've been doing software dev for over 20 years and one of the things I'm known for is building very stable systems. Part of the way I do this is by not allowing myself to use these sorts of things as a defense. When designing and/or building a system I ask: What should not be? Then I build the system to actively look for those situations. Put another way, I don't build systems with the assumption that there are no bugs. Too many developers push the responsibility outside of themselves. As if bugs are inevitable, therefore the fallout from bugs is inevitable. You just do a root cause analysis and move on rather than asking what you could have done differently to avoid the fallout. I've lost count of the number of times systems I've built have actively refused to do something and then sent out a notification explaining why. My point here is that you're doing yourself a disservice by insisting that root cause analysis should be enough. Yes it's important, but it's not enough. Some things simply should not be, and they're avoidable. The problem is that many companies don't really care.
  - aflag 6y ago
    I don't think it's rude to point out someone is missing the point, though I can see why you're considering that given the overall aggressive tone of your messages. Let's backtrack, then. My main point is that scolding an individual for a problem in production is not going to improve the quality of the software produced by a company at all. Do you disagree with that?
    - RandoHolmes 6y ago
      Not relevant. You responded to another poster, I responded to that response to try and explain what the other poster was trying to say. Neither of us said anything about scolding anyone, that's a strawman.
      - 6y ago

aflag 6y ago

I'm not sure if that employee fucked up. That may be company policy. Support people usually follow a script and they very rarely venture much beyond that. Partially because they lack technical knowledge and partially because it could actually get them in trouble. If I understand it correctly and you were calling your ISP at 6am, I don't think the person you were talking to was a developer. That said, I have no expertise in customer relations, so I wouldn't know if they were following good practices or not in that instance. I get your point that people make bad decisions, but in software development, those bad decisions shouldn't break the user experience, but decrease the developer's (and/or the team's) productivity instead. Doing root cause analysis is part of the process to achieve that, as it can give insight on how to avoid that class of problems in future. That said, if someone is not doing a good job, they'd hopefully figure it out by themselves, but constructive feedback can also go a long way. Ultimately, if you have a good process in place, it should help you to make an educated assessment of who is underperforming (eg.: their PRs take very long to merge, they are full of beginner's mistakes, their code is never properly tested, their releases are always rolled back a few times until they get it right, etc). All of that without playing the blame game on the (hopefully) rare ocasion that a major bug is found in production.

RandoHolmes 6y ago
This is probably going to come across rude, but I feel like it needs to be said. nothing in your post was really relevant to this discussion. The fact that it may have been a company policy or that the person wasn't a developer is completely irrelevant to the larger idea. It's literally missing the forest for the trees. I've been doing software dev for over 20 years and one of the things I'm known for is building very stable systems. Part of the way I do this is by not allowing myself to use these sorts of things as a defense. When designing and/or building a system I ask: What should not be? Then I build the system to actively look for those situations. Put another way, I don't build systems with the assumption that there are no bugs. Too many developers push the responsibility outside of themselves. As if bugs are inevitable, therefore the fallout from bugs is inevitable. You just do a root cause analysis and move on rather than asking what you could have done differently to avoid the fallout. I've lost count of the number of times systems I've built have actively refused to do something and then sent out a notification explaining why. My point here is that you're doing yourself a disservice by insisting that root cause analysis should be enough. Yes it's important, but it's not enough. Some things simply should not be, and they're avoidable. The problem is that many companies don't really care.
- aflag 6y ago
  I don't think it's rude to point out someone is missing the point, though I can see why you're considering that given the overall aggressive tone of your messages. Let's backtrack, then. My main point is that scolding an individual for a problem in production is not going to improve the quality of the software produced by a company at all. Do you disagree with that?
  - RandoHolmes 6y ago
    Not relevant. You responded to another poster, I responded to that response to try and explain what the other poster was trying to say. Neither of us said anything about scolding anyone, that's a strawman.
    - 6y ago