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.
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.
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.
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.
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.
See another post by this author for a similar tone: 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.
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.
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.
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.
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.
I don't mind that way of communicating, but I'm also absolutely fine with Linus' style. The comments in defense of this had a bit of a cultish feel ("she has earned the right to talk that way about people!!111"), but I gather that's more because people know her and may consider her a friend, so their perception is changed.
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.
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.
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.
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.
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 ...”
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.
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.
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.
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.