4 ms·

> What do you when a couple teammates walk up to your desk out of nowhere, abruptly interrupt your coding zone, and ask you why the build broke when you changed

> What do you when a couple teammates walk up to your desk out of nowhere, abruptly interrupt your coding zone, and ask you why the build broke when you changed the FoobarService to return X instead of Y when Z? They can't release the latest features until it's fixed! What you were doing isn't important anymore, you're holding up everything! This should have been caught before it was an emergency, through standard processes such as integration and unit testing. > ... you're oncall, and angry users, coworkers or your manager start asking you what's wrong? If your coworkers and managers are angry during an outage, or asking anything other than "what can I do to help", they're not helping. > Sometimes the co-workers involved aren't gentle about things in the heat of the moment ... Those coworkers need to be instructed in proper workplace behavior. The time to be critical about work is before an emergency occurs. Institute policies to ensure code quality and IT robustness, define roll-back plans to be enacted in case of failure, and supply other policies, procedures, and evaluation criteria necessary to steer your employees to ensure that the chance of success is maximized (and the chance of outage is minimized). When (not if) the shit hits the fan, you -- and all your employees -- are prepared for it. If a nervous manager is still checking in every 2 minutes instead of asking how they can help, it's your job to MAKE THEM STOP. This strategy is how you prevent most failures, and make the ones that happen manageable. Your strategy is how you create failures, and then make them worse for everyone involved when they happen.

badgar 14y ago
> This should have been caught before it was an emergency, through standard processes such as integration and unit testing. Things always go wrong in the development cycle. Problems happen. Conflicts between individuals occur. I was giving an example. Are you asserting these issues don't arise in the workplace? Or that my example is of a rare situation in software development? > If your coworkers and managers are angry during an outage, or asking anything other than "what can I do to help", they're not helping. People sometimes do unhelpful things. Sometimes people even make emotional decisions about what to say to others. Are you aware of the fallibility of man? > Those coworkers need to be instructed in proper workplace behavior. They likely will be. Have you met engineers? A lot of them could use some workplace etiquette training! Until then, you need to do your job - you can't just go home because it's stressing you out. This is something that happens in every single workplace. If you can't handle it, you aren't a very valuable employee. > This strategy is how you prevent most failures, and make the ones that happen manageable. Your strategy is how you create failures, and then make them worse for everyone involved when they happen. This, and the rambling before it, is completely off-topic. I have no idea why you're rambling on and on about software development practices when the issue I'm addressing is that social stress always exists at work. If you feel my examples are unsatisfactory, but don't have any issue with my core argument, then you aren't being helpful. If you have an issue with my core argument, please address it instead of nitpicking my examples.
- pifflesnort 14y ago
  Your examples are all cases where someone creates social stress by reacting poorly to avoidable, stressful situations. Your goal seems to be to hire people that will put up with these avoidable stresses. My goal is to build an mature workplace where we avoid creating unnecessary social stresses by applying collective wisdom and experience to plan ahead. This is one of the many difference between engineering and hacking.

badgar 14y ago

> This should have been caught before it was an emergency, through standard processes such as integration and unit testing. Things always go wrong in the development cycle. Problems happen. Conflicts between individuals occur. I was giving an example. Are you asserting these issues don't arise in the workplace? Or that my example is of a rare situation in software development? > If your coworkers and managers are angry during an outage, or asking anything other than "what can I do to help", they're not helping. People sometimes do unhelpful things. Sometimes people even make emotional decisions about what to say to others. Are you aware of the fallibility of man? > Those coworkers need to be instructed in proper workplace behavior. They likely will be. Have you met engineers? A lot of them could use some workplace etiquette training! Until then, you need to do your job - you can't just go home because it's stressing you out. This is something that happens in every single workplace. If you can't handle it, you aren't a very valuable employee. > This strategy is how you prevent most failures, and make the ones that happen manageable. Your strategy is how you create failures, and then make them worse for everyone involved when they happen. This, and the rambling before it, is completely off-topic. I have no idea why you're rambling on and on about software development practices when the issue I'm addressing is that social stress always exists at work. If you feel my examples are unsatisfactory, but don't have any issue with my core argument, then you aren't being helpful. If you have an issue with my core argument, please address it instead of nitpicking my examples.

pifflesnort 14y ago
Your examples are all cases where someone creates social stress by reacting poorly to avoidable, stressful situations. Your goal seems to be to hire people that will put up with these avoidable stresses. My goal is to build an mature workplace where we avoid creating unnecessary social stresses by applying collective wisdom and experience to plan ahead. This is one of the many difference between engineering and hacking.