6 ms·

Just reading that, the tone of this person made me cringe. I definitely would never want to work with him/her. I can feel the negativity and attitude in almost

Just reading that, the tone of this person made me cringe. I definitely would never want to work with him/her. I can feel the negativity and attitude in almost every sentence. The right thing to do would be to help this person achieve their goals while maintaining reliability of the operation. Calling a co-worker who is just trying to get something done a rando is the epitome of toxicity. She wouldn't last 5 minutes with that attitude in my organization.

tonyhb 7y ago
Yeah. The author has a good point about _the specific way the co-worker went about things_ being wrong. But there was also a lack of understanding to explain things. I'm assuming we, the blog audience, had a better explanation for "no, just no" than the co-worker did. See another post by this author for a similar tone: https://news.ycombinator.com/item?id=22277582 https://news.ycombinator.com/item?id=22277582. Maybe work right now is tough. It sounds that way. All that said, a solid takeaway is that sometimes people are naive and you need to say no. The next step is: alongside saying no, ask what their aim is. You're saying no to the solution and you don't know the problem.
bluedino 7y ago
It sounds like the person was told to stop and directed to the people to discuss the correct solution with. And then it sounds like the person did it anyway, at a later date, and broke shit. If that person repeated that behavior it is someone I wouldn't want on the team, or at least having access to certain systems.
HarryHirsch 7y ago
Don't know about the tone. What worries me is the company. There's no procedure for updates that have far-reaching ramifications? Yeah, can see why that would wear you down.
- nbm 7y ago
  There usually are procedures. Doesn’t stop people trying to work around them anywhere I’ve heard of. And I’ve yet to find any set of procedures that cover all possible cases. So you still need people to apply good judgement when the procedures don’t cover situations, or if the procedures currently would allow something that shouldn’t be allowed. Like: “no, even though we have a way to safely roll new libraries out, we won’t allow you to add this library to all front-ends, you should follow best practice and use ...”
cwzwarich 7y ago
The author apparently works for Facebook, which makes all of the vague language in the story make a lot more sense. Would Facebook really let somebody do this to every external frontend server on a Sunday without some boring authorization first? The authorization could simply be denied with a boilerplate response about the right way to do things, with less emotional resources spent than the author apparently did.
- jcims 7y ago
  The author is a veteran in the industry and stories crop up from various aspects of her entire career. I wouldn't attribute any of them to a particular employer unless she indicates it directly or cough indirectly.
gruturo 7y ago
The kind of people who expect to push untested code to a production farm without the slightest intuition that it may impact reliability and operations are unfortunately a fixture of certain organizations, and after having to argue with them for the 100th time, people do get a bit jaded. Unfair to call the coworker a rando, but these people did bring systems down at literally the first occasion they managed to ship their code, despite having received advice. I have a similar situation maybe once or twice a year (used to be worse when working in other places) and do my best to defuse the situation while maintaining politeness and etiquette, but this is the tone I'd then use to describe the story to some friends.
newnewpdro 7y ago
Their actual communications with the colleague didn't strike me as toxic at all. It's a blog post, I took their use of "rando" as an artistic choice in emphasizing this person had utterly neglected to coordinate with any of the stakeholders beforehand, with the intent of going into production the next day. From the perspective of the stakeholders, the person was effectively a stranger, and that's the crux of the matter being described.
dang 7y ago
Please don't cross into personal attack here. Besides being mean and against the rules, it makes for boring reading. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- craftyguy 7y ago
  > it makes for boring reading I didn't find this readers interpretation of the author's behavior to be boring. I can see how she may come across as being overly combative (though I agree with her goal). Your frequent comments about what you find to be 'boring' is boring.
  - miscPerson 7y ago
    @dang likes Overton manipulation via pretending to address decorum — a common social control tactic. In this case, the person broke the unspoken rule of being critical of a community member @dang personally likes, so we get a grumpy mod post discussing the decorum, but really signaling that some people in the community can’t be criticized.
  - Cogito 7y ago
    For what it's worth, I think it's ok for those comments to be boring. The root comment has been hidden, and the mod (who probably hid it) has replied to it stating why it was hidden. That we can see moderation is a good thing; that moderation is 'boring' is to be expected.
  - dang 7y ago
    I mean the word 'boring' in the HN sense of not intellectually interesting. Something can still be exciting even if it's boring in this way. It's boring because there are only so many ways to denounce something as "the epitome of toxicity", "this person made me cringe", and so on, which means the patterns of denunciation get recycled a lot. That makes them predictable, and this site exists for things that aren't predictable. Another way of putting it is that indignation tends to melt down to a few formulations that get repeated a lot, where intellectual curiosity looks for what is new and different in a situation, and then has a new and different reaction to that. Since we want HN to be a site for intellectual curiosity, it's important not to feed indignation too much. It quickly overwhelms curiosity if allowed to (especially on the internet); therefore we need to moderate it. You're right that the moderation comments are boring; that's because they're also predictable. If it helps at all, they're even more tedious to write than they are to read.
x0x0 7y ago
Trying to add a brand new, non-load-tested, non-hardened binary to a site with actual reliability requirements 12-24h before your deploy is not behavior that demands to be taken seriously. Someone serious would have talked to the reliability team months, if not quarters, ahead of time and learned eg transport and cutout requirements. There are also almost certainly other requirements, eg run books. Let alone on a Sunday afternoon. The whole thing smells like someone knew there was a process to do X, figured their X wouldn't pass, and tried to bypass the process.
toyg 7y ago
Rachel (who is here also as rachelbythebay since 2011) is a very old-school sysadmin in many ways, but she’s earnt her stripes [1]. If she says something is stupid, chances are that it is. [1] https://medium.com/wogrammer/rachel-kroll-7944eeb8c692 https://medium.com/wogrammer/rachel-kroll-7944eeb8c692
- luckylion 7y ago
  The parent wasn't claiming it wasn't stupid or wrong, they were talking about the tone. It's not quite Linus rejecting a patch with some choice insults, but it's certainly in that direction.
  - zentiggr 7y ago
    She has seen and written about enough to be entirely justified in her tone. And she's always got an overall point about how to run things better / improve process / get newbies up to speed and past the 'every commit breaks things'. I'd take the time to go read the rest of her posts I haven't seen, and definitely learn a bit about surviving sysadmin work in larger organizations in the process.
    - snlnspc 7y ago
      Linus has also seen and written about a lot. Would you say that he was justified in his tone prior to his apology for his tone? Granted that his tone and her tone were very different, but, imo, as a reader of her posts, this wasn't necessary. Educating junior devs is more productive than considering them randos.
      - toyg 7y ago
        > Would you say that he was justified in his tone prior to his apology for his tone? I'll take my downvotes here, but personally I think Linus with that apology crossed the threshold into old age. Quoting Tomasi di Lampedusa: > The Prince who had found the town unchanged, was found much changed himself, whom never before would have used such accommodating words; and since then, invisible, began the decline of his prestige.
rossdavidh 7y ago
Well, yes and no. In large organizations, with complex things that can cause a lot of problems quickly, you do often need to have a few people like this. They are, hopefully, not anyone's boss, but they may be, for example, the DBA in an organization where everyone is hitting the same database and if it gets hung up everything in the company grinds to a halt. The "grizzled veteran", aka grizzly bear. The usual result is that if someone finds out they have to do something that involves asking the grizzly bear a question, they make sure to do lots of due diligence first, and maybe ask other people who might know the answer, and only bother the grizzly bear if they absolutely have to. You definitely don't want to have an organization with lots of grizzly bears, but it is also the case that a particularly high-stakes system sometimes does need a grizzly bear paying attention to it, to keep that system from giving everyone a great "learning opportunity" on a regular basis. If that's a less high-stakes system, then that learning opportunity is fine, but if it's something that nearly everyone relies on in a large organization, you cannot afford that many outages. Not saying you're wrong in your evaluation, just saying that the same personality type is occasionally useful, or even necessary, in certain situations.
Spooky23 7y ago
Her behavior isn’t toxic in the least. Toxic is playing dumb and bypassing controls on a Sunday to get your boss off your back, while dumping a bucket of shit over everyone who is obliged to support the company.
- HarryHirsch 7y ago
  Toxic is playing dumb and bypassing controls on a Sunday It's actually not, that's just going along to get along. Ship enough features, get a promotion. The higher-ups that enable the circus are the toxic ones.
bdamm 7y ago
Well, you’re right. But there’s a bigger deal at play here, which is why does a junior lone dev have access to deploy randomly to the business critical services? Is this what devops has become, carte-blanche access across the board? Somehow I thought the norm was better than this.
- snlnspc 7y ago
  This was my main takeaway from this post as well.
rsynnott 7y ago
> The right thing to do would be to help this person achieve their goals while maintaining reliability of the operation. I think in most places, if your goal is to make major production changes on a weekend, the right answer is ‘no’. Seems like she handled it fairly diplomatically, all things considered. And as it turns out, later on the rando in question broke the internal site. So she was probably right to tell them to step away from the keyboard slowly when they were trying to do it on production.
hibbelig 7y ago
It was Sunday. The person wanted to deploy something to meet a deadline the next day. But from what I understand there was still some months of work to do on this component before it was production ready. I feel it’s totally justified to just make sure that this Sunday they don’t break production. Helping the team get it right can wait until Monday. Rachel doesn’t say what exactly was being communicated. But maybe her response on the weekend made that clear. In fact that’s what I assumed when I read the article.

tonyhb 7y ago

Yeah. The author has a good point about _the specific way the co-worker went about things_ being wrong. But there was also a lack of understanding to explain things. I'm assuming we, the blog audience, had a better explanation for "no, just no" than the co-worker did. See another post by this author for a similar tone: https://news.ycombinator.com/item?id=22277582 https://news.ycombinator.com/item?id=22277582. Maybe work right now is tough. It sounds that way. All that said, a solid takeaway is that sometimes people are naive and you need to say no. The next step is: alongside saying no, ask what their aim is. You're saying no to the solution and you don't know the problem.

bluedino 7y ago

It sounds like the person was told to stop and directed to the people to discuss the correct solution with. And then it sounds like the person did it anyway, at a later date, and broke shit. If that person repeated that behavior it is someone I wouldn't want on the team, or at least having access to certain systems.

HarryHirsch 7y ago

Don't know about the tone. What worries me is the company. There's no procedure for updates that have far-reaching ramifications? Yeah, can see why that would wear you down.

nbm 7y ago
There usually are procedures. Doesn’t stop people trying to work around them anywhere I’ve heard of. And I’ve yet to find any set of procedures that cover all possible cases. So you still need people to apply good judgement when the procedures don’t cover situations, or if the procedures currently would allow something that shouldn’t be allowed. Like: “no, even though we have a way to safely roll new libraries out, we won’t allow you to add this library to all front-ends, you should follow best practice and use ...”

cwzwarich 7y ago

The author apparently works for Facebook, which makes all of the vague language in the story make a lot more sense. Would Facebook really let somebody do this to every external frontend server on a Sunday without some boring authorization first? The authorization could simply be denied with a boilerplate response about the right way to do things, with less emotional resources spent than the author apparently did.

jcims 7y ago
The author is a veteran in the industry and stories crop up from various aspects of her entire career. I wouldn't attribute any of them to a particular employer unless she indicates it directly or cough indirectly.

gruturo 7y ago

The kind of people who expect to push untested code to a production farm without the slightest intuition that it may impact reliability and operations are unfortunately a fixture of certain organizations, and after having to argue with them for the 100th time, people do get a bit jaded. Unfair to call the coworker a rando, but these people did bring systems down at literally the first occasion they managed to ship their code, despite having received advice. I have a similar situation maybe once or twice a year (used to be worse when working in other places) and do my best to defuse the situation while maintaining politeness and etiquette, but this is the tone I'd then use to describe the story to some friends.

newnewpdro 7y ago

Their actual communications with the colleague didn't strike me as toxic at all. It's a blog post, I took their use of "rando" as an artistic choice in emphasizing this person had utterly neglected to coordinate with any of the stakeholders beforehand, with the intent of going into production the next day. From the perspective of the stakeholders, the person was effectively a stranger, and that's the crux of the matter being described.

dang 7y ago

Please don't cross into personal attack here. Besides being mean and against the rules, it makes for boring reading. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

craftyguy 7y ago
> it makes for boring reading I didn't find this readers interpretation of the author's behavior to be boring. I can see how she may come across as being overly combative (though I agree with her goal). Your frequent comments about what you find to be 'boring' is boring.
- miscPerson 7y ago
  @dang likes Overton manipulation via pretending to address decorum — a common social control tactic. In this case, the person broke the unspoken rule of being critical of a community member @dang personally likes, so we get a grumpy mod post discussing the decorum, but really signaling that some people in the community can’t be criticized.
- Cogito 7y ago
  For what it's worth, I think it's ok for those comments to be boring. The root comment has been hidden, and the mod (who probably hid it) has replied to it stating why it was hidden. That we can see moderation is a good thing; that moderation is 'boring' is to be expected.
- dang 7y ago
  I mean the word 'boring' in the HN sense of not intellectually interesting. Something can still be exciting even if it's boring in this way. It's boring because there are only so many ways to denounce something as "the epitome of toxicity", "this person made me cringe", and so on, which means the patterns of denunciation get recycled a lot. That makes them predictable, and this site exists for things that aren't predictable. Another way of putting it is that indignation tends to melt down to a few formulations that get repeated a lot, where intellectual curiosity looks for what is new and different in a situation, and then has a new and different reaction to that. Since we want HN to be a site for intellectual curiosity, it's important not to feed indignation too much. It quickly overwhelms curiosity if allowed to (especially on the internet); therefore we need to moderate it. You're right that the moderation comments are boring; that's because they're also predictable. If it helps at all, they're even more tedious to write than they are to read.

x0x0 7y ago

Trying to add a brand new, non-load-tested, non-hardened binary to a site with actual reliability requirements 12-24h before your deploy is not behavior that demands to be taken seriously. Someone serious would have talked to the reliability team months, if not quarters, ahead of time and learned eg transport and cutout requirements. There are also almost certainly other requirements, eg run books. Let alone on a Sunday afternoon. The whole thing smells like someone knew there was a process to do X, figured their X wouldn't pass, and tried to bypass the process.

toyg 7y ago

Rachel (who is here also as rachelbythebay since 2011) is a very old-school sysadmin in many ways, but she’s earnt her stripes [1]. If she says something is stupid, chances are that it is. [1] https://medium.com/wogrammer/rachel-kroll-7944eeb8c692 https://medium.com/wogrammer/rachel-kroll-7944eeb8c692

luckylion 7y ago
The parent wasn't claiming it wasn't stupid or wrong, they were talking about the tone. It's not quite Linus rejecting a patch with some choice insults, but it's certainly in that direction.
- zentiggr 7y ago
  She has seen and written about enough to be entirely justified in her tone. And she's always got an overall point about how to run things better / improve process / get newbies up to speed and past the 'every commit breaks things'. I'd take the time to go read the rest of her posts I haven't seen, and definitely learn a bit about surviving sysadmin work in larger organizations in the process.
  - snlnspc 7y ago
    Linus has also seen and written about a lot. Would you say that he was justified in his tone prior to his apology for his tone? Granted that his tone and her tone were very different, but, imo, as a reader of her posts, this wasn't necessary. Educating junior devs is more productive than considering them randos.
    - toyg 7y ago
      > Would you say that he was justified in his tone prior to his apology for his tone? I'll take my downvotes here, but personally I think Linus with that apology crossed the threshold into old age. Quoting Tomasi di Lampedusa: > The Prince who had found the town unchanged, was found much changed himself, whom never before would have used such accommodating words; and since then, invisible, began the decline of his prestige.

rossdavidh 7y ago

Well, yes and no. In large organizations, with complex things that can cause a lot of problems quickly, you do often need to have a few people like this. They are, hopefully, not anyone's boss, but they may be, for example, the DBA in an organization where everyone is hitting the same database and if it gets hung up everything in the company grinds to a halt. The "grizzled veteran", aka grizzly bear. The usual result is that if someone finds out they have to do something that involves asking the grizzly bear a question, they make sure to do lots of due diligence first, and maybe ask other people who might know the answer, and only bother the grizzly bear if they absolutely have to. You definitely don't want to have an organization with lots of grizzly bears, but it is also the case that a particularly high-stakes system sometimes does need a grizzly bear paying attention to it, to keep that system from giving everyone a great "learning opportunity" on a regular basis. If that's a less high-stakes system, then that learning opportunity is fine, but if it's something that nearly everyone relies on in a large organization, you cannot afford that many outages. Not saying you're wrong in your evaluation, just saying that the same personality type is occasionally useful, or even necessary, in certain situations.

Spooky23 7y ago

Her behavior isn’t toxic in the least. Toxic is playing dumb and bypassing controls on a Sunday to get your boss off your back, while dumping a bucket of shit over everyone who is obliged to support the company.

HarryHirsch 7y ago
Toxic is playing dumb and bypassing controls on a Sunday It's actually not, that's just going along to get along. Ship enough features, get a promotion. The higher-ups that enable the circus are the toxic ones.

bdamm 7y ago

Well, you’re right. But there’s a bigger deal at play here, which is why does a junior lone dev have access to deploy randomly to the business critical services? Is this what devops has become, carte-blanche access across the board? Somehow I thought the norm was better than this.

snlnspc 7y ago
This was my main takeaway from this post as well.

rsynnott 7y ago

> The right thing to do would be to help this person achieve their goals while maintaining reliability of the operation. I think in most places, if your goal is to make major production changes on a weekend, the right answer is ‘no’. Seems like she handled it fairly diplomatically, all things considered. And as it turns out, later on the rando in question broke the internal site. So she was probably right to tell them to step away from the keyboard slowly when they were trying to do it on production.

hibbelig 7y ago

It was Sunday. The person wanted to deploy something to meet a deadline the next day. But from what I understand there was still some months of work to do on this component before it was production ready. I feel it’s totally justified to just make sure that this Sunday they don’t break production. Helping the team get it right can wait until Monday. Rachel doesn’t say what exactly was being communicated. But maybe her response on the weekend made that clear. In fact that’s what I assumed when I read the article.