I think every organization above a certain size necessarily ends up with informal (or sometimes formal) groups of "adults in the room" that handle important things in good faith, as a coordinated team. It's inherently discriminatory against a certain type of employee (one who would rather metagame the organization itself rather than address the market/customers/ops) but quite necessary.
One of the best things you can do when you join a new organisation is figure out who those people are.
They often know where the bodies are buried (or that obscure document stored on a documentation system from two generations ago that was deprecated but never removed "just in case" that describes exactly the system you are currently looking at wondering "wtf").
In an idealised world it wouldn't happen but I've never managed to work anywhere close to that.
I've heard a strategy to start with asking "who do you respect the most in this org?" or "who is the most knowledgeable person in the org?". Keep repeating that across every 1:1 and you may eventually build an influence graph.
> one who would rather metagame the organization itself rather than address the market/customers/ops
Saved for future reference. My company has an exploding number of metagamers with an ever shrinking number of "adults in the room". It's stagnating hard.
Typically, this is a problem of success. Success attracts metagamers, which leads to less success, so they leave. Repeat until insolvency/heat death of the universe.
jwz once put it when talking about netscape: people who want to go to work for a successful company instead of people who want to go to work for a company and make it successful.
Problem is (as it seems the case in the author's case) when this group (I really loathe the term "adults in the room", by exclusion the rest of people are children or to be treated as such) has people with power that are "well actually" people just there to pontificate from their inflated egos without letting others do their jobs.
I have been fortunate enough to land in a part of my employer's technical culture governed -- roughly -- by this sort of idea, albeit not one that's written down anywhere. The people in the Slack channels (IRC, back in the day, but time marches on...) that I frequent are the ones who provide some of the backchannel cross-team communication and technical analysis that make our company work.
I like this article a lot; if I were trying to replicate the community I've got now, I'd probably start with this.
One real issue here is Slack being used for a RFC rather than something like a github issue.
Slack is a great medium for realtime chatting but someone jumping into a conversation without context is exactly where it falls down. "Ubuntu is doomed" is exactly the sort of comment someone skimming to catch up will fixate on and jump to a conclusion - even with a code of conduct...
You need a place for conversations to exist that promotes asynchronous communication. A github issue is a nice starting point since someone can create a summary at the top. The summary can be continuously updated. And an intentionally slower/more thought out discussion can follow.
"RFC: Company$ moving away from ubuntu" is exactly the sort of productive GH issue I've seen at past companies.
Of course GH issues regularly devolve - lots of examples dropped into HN over the years where people get angry/inappropriate at some poor open source maintainer, but it is still an improvement over slack.
The decision had already been made, and not by any of the people in that chat. We were shooting the shit about the impending change and what it meant in terms of our stuff running on it going forward.
You ever, you know, just talk with your coworkers? And not just sling bugs at them?
Slack is being used as a substitute for all kinds of communication patterns where it shouldn't be and people tend to be assholes about it.
For example, mandatory-participation announcement channels that don't actually require any action on the part of the receiver. They're used for every corner of the company to self-congratulate and should be emails instead of notifications.
For anyone who can make these decisions in their own comapnies, if a channel's messages:
- do not require immediate attention, and
- do not require an action,
for the love of god, do not make it a mandatory-participation channel.
I obviously don't know all the details here, as this is, by definition, just one person's version of events. That said, I'm always highly skeptical of any account that essentially paints many/most others in the org as the source of the dysfunction, and if only they implemented my brilliant idea would things get fixed.
All large organizations have varying degrees of dysfunction, some more than others. Sometimes that dysfunction is toxic, but other times it's just a result of people being human with different opinions of how best to do things. Coming in to a new organization and making an announcement that is some version of "you're doing it wrong", unless you're very high up in the org, is rarely successful.
> I'm always highly skeptical of any account that essentially paints many/most others in the org as the source of the dysfunction, and if only they implemented my brilliant idea would things get fixed.
I didn't get that take from the article at all; I've been a part of one of the orgs she's describing and had the same experience. Over a couple years we went from a raucous, rough-and-tumble culture of open debate on the technical merits to a "polite" "respectful" org where nobody dared pop their head over the trench and bad decisions were allowed to continue unchallenged until they were nigh-irreversible. Much of it was due to a single executive's behavior. He was a big bully, always had to be right, and you knew that if you ever expressed an opinion about anything in his domain, he'd come after you like a fucking pitbull and worry your flesh until you submitted, using the power of his office and his connection to the founder to ensure you bent the knee.
"[A] raucous, rough-and-tumble culture of open debate on the technical merits"
does not conflict with
"a "polite" "respectful" org"
while
"a big bully, always had to be right, and you knew that if you ever expressed an opinion about anything in his domain, he'd come after you like a fucking pitbull and worry your flesh until you submitted, using the power of his office and his connection to the founder to ensure you bent the knee"
has, in my experience more in common with not being the second. In fact, in my experience, what I think you mean by "rough-and-tumble culture" supports the pitbulls much more than any form of making good decisions.
Boy I really wish I'd written a little more. Serves me right for underestimating the breadth of experiences on this board, and how that can lead to drastically different takes.
If you were to argue that the pre-fear environment was unprofessional, exclusionary, immature, and that it often led to miscommunications and hard feelings, I'd have a hard time disagreeing. It's certainly not my preferred style (any more) and I think we can all do better and be nicer without giving up the meeting of the minds that's so essential to progress, at any scale.
But what came after? It was polite—because nobody talked. It was respectful—because everybody was afraid. Afraid I can't go into further detail, but it led to far greater harm in the long run, for the whole world, not just the company.
Many (most?) of the comments on this and similar threads seem to come from a belief that any attempt to encourage or (heaven forbid) enforce polite and respectful communication automatically mean a culture of fear and silence. Which is weird, given that HN discussions are usually reasonably polite and respectful, and that enforcement is reasonably visible. I apologize if I assumed your comments were from that mold. I was mistaken.
But I still disagree that an appearance politeness and respect or attempt to promote them is either a sign of, or responsible for, harm to a company (or the world).
Oh, and I did remember a decent example: IBM in the 1990s up through 2005 (that being the last time I worked there). He who talked loudest wins. Anyone who could spew tech-sounding gibberish like a Star Trek screenwriter at high volume was apparently automatically made a Technical Fellow. It led to a long series of bad technical decisions---and anyone who disagreed was treated unprofessionally and immaturely, and excluded---that ultimately hollowed-out the company.
I assume the "" are relevant in "polite" "respectful" (i.e. a culture thats only very superficially so/only when it is convenient), and that's very much in conflict with open debate.
> Over a couple years we went from a raucous, rough-and-tumble culture of open debate on the technical merits to a "polite" "respectful" org where nobody dared pop their head over the trench and bad decisions were allowed to continue unchallenged until they were nigh-irreversible.
I don't think polite and respectful are in opposition to open debate. If someone can't make a point in a debate without being polite and respectful, I really don't want to work with them.
I have found that it's very, very easy for some people operating in bad faith to turn ANY opposing argument into a violation of "politeness" and "respect". A real example from an internal discussion I witnessed once:
A: We should use $FRAMEWORK for everything in $APP because it provides a better developer experience. Sure, long list views might be slower, but we hardly ever need to care about long lists.
B: Almost every screen in $APP is a long list! I don't think we should compromise performance on $FEATURE, $FEATURE, or $FEATURE for this -- benchmarks suggest they'd be four to five times slower.
A: [to B's manager, cc HR] By making such an obvious statement as "almost every screen in $APP is a long list" in a public Slack channel, B made me feel uncomfortable by implying I wasn't familiar with $APP, even though I've worked on it for several years. That is an unacceptably disrespectful way to hold a technical discussion.
How much harder is it for someone operating in bad faith to turn the lack of politeness and respect to their advantage? My personal experience would suggest it's even easier.
[dang's pretty good about enforcing politeness and respect, so I won't try to present any examples. :-)]
AFAICT, B was polite and respectful while engaging in open debate. The problem here is A, not B. The problem is _not_ the requirement to be polite and respectful.
> AFAICT, B was polite and respectful while engaging in open debate.
Yep.
> The problem here is A, not B.
I'm pretty sure the implied problem is "B's manager" and "HR".
> The problem is _not_ the requirement to be polite and respectful.
The problem is that this requirement is not seperable from the details of how it's interpreted and enforced, and in a plurality of organizations that talk about "politeness" and "respect", it is in fact interpreted and enforced in a A(-hole)-ish manner, rather than a manner based on actual politeness and respect. Conversely, organizations that care about actual politeness and respect generally don't belabor the point as much as those that use it as a flimsy excuse, so people tend[0] to see a explicitly "'polite' 'respectful' org" as warning sign of the latter.
0: rightly or wrongly; I'm not sure how the statistics work out on that one.
TL;DR: as other people have pointed out, the scare quotes are there for a reason.
Sure, but now the case is before HR and B has to waste cycles defending themselves. Or, depending on just how dysfunctional the place is, they never even hear of the false accusation until months later when it has already metastasized through the organization.
Obviously people should be polite and respectful, but when there is too much posturing around these facts, it's easy for malicious actors to weaponize.
Don't a lot of companies strive for high "psychological safety" these days for the very reason of encouraging open debate, ensuring that bold ideas are actually given an airing rather than held back?
> Coming in to a new organization and making an announcement that is some version of "you're doing it wrong",
Is hurting your career if your are low level. If you are high level, it's hurting the team and the company. A new hire exec who thinks they know more than the veteran staff is a shortcut to destroying a company.
Most of us in software engineering have, at some point, encountered someone who does not see a difference between technical criticisms of a system and personal attacks on its designers and authors. This is an understandable error in a junior engineer, an irritating bad habit in a mid-tier engineer, and a problem in a senior person. In all cases, the answer often winds up being finding a way around them, much as this describes.
I've been places where such people have found their way to technical leadership. Finding ways to improve things can rapidly become exceptionally difficult.
At this point my only way forward is to have a personal blocklist of people whose technical leadership decisions I refuse to ever be subject to again. It's a shame, because some of them are also brilliant engineers.
I'm well into the senior years of my career, and I have certainly been all of these things. But a fellow engineer taking things personally is not as problematic as the behavior that often accompanies it: never admitting error.
Years ago I heard the phrase "set to bozo bit" to describe what you're calling a personal blocklist. It was described as an anti-pattern, and setting the bozo bit as a poor choice in nearly every case. It combines the bad parts of an ad hominem attack with the bad parts of personal arrogance and negativity. Don't think your other teammates won't realize you've "blocked" a teammate. Some of them will react badly, and potentially see you as arrogant.
I end with this quote from E.W. Dijkstra:
We shall do a much better programming job, provided that we approach the task with a full appreciation of its tremendous difficulty, provided that we stick to modest and elegant programming languages, provided that we respect the intrinsic limitations of the human mind and approach the task as Very Humble Programmers.
I am well into those years myself, and respectfully, while I agree with the importance of being humble and remembering the incredible challenge of the task, the bozo bit can be very valuable. Not everyone in this industry is a hardworking talented joy operating in good faith.
To give a concrete example, at one point in my career, I was leading a team trapped on a death march project. We did not have the option of abandoning it, due to a meaningful fraction of the company’s revenue riding on its success. We did not have the option of more resources for the usual reasons. And we did not have the option of more time, because executives had already de facto announced when it would be done. Unfortunately, our direct upstream dependency in the company saw us as a rival - because they had wanted to own this project - and spent multiple years trying every way they could to sabotage and undermine us, including lying to us in meetings, lying about us to others, changing key system aspects to make our problem harder to solve, denying access to critical resources and people, pitting vendors against each other, and giving unsolicited negative peer reviews to people working on our team.
To say this was a difficult experience would be an understatement. I had four employees quit. I myself started having panic attacks twice a week and was in therapy for over a year to work through the crippling anxiety I was feeling every waking moment. I still have persistent health issues from the incredible stress of those years. We landed the thing, got our pats on the back, and then I quit.
The main guy responsible for this campaign of sabotage and mistreatment was much higher level than me in the company and punching down as hard as he could. He left successfully for a larger role at another company once it became clear that our team was going to hurdle any roadblock he threw at us. It was a knock-down, drag-out fight. I will never do anything like it again.
If I ever found myself working with that person or any of his leads again in any capacity I would quit instantly. The bit is set.
I also agree with the utility of the bozo bit. I worked somewhere where a long time engineer got Peter/Dilbert Principled at just the level of Team Lead. Once you've done four years or so in the org, they don't fire you just motivate you to quit. Anyway, this person gets moved into a Lead role with a team of one person where he can do the least harm. He's awful to work with, can't communicate properly and derails every meeting he's in with complete tangents.
Why going through all of that (honest curiosity)? 4 people quit and you had panic attacks just to deliver something for a company that didn’t care much. Wouldn’t it have been easier that the whole team left early on? Your mental health would be way better, as well as of your teammates.
When you’re in the thick of it, the fog of war is real.
It’s hard to overstate how hard it is to leave this kind of project as a manager. You spend years of your life building relationships with engineers and trying (and sometimes failing, admittedly, but trying) to protect them. You know the situation is a disaster and you want to get out of it. But you’re afraid of letting down your people and hurting their careers. You’re afraid the next person won’t be able to protect them as well. You’re afraid of losing the years in your resume and not accomplishing anything. You’re afraid of being a failure if you give up. When your body is breaking down due to the stress, you’re afraid to lose your health insurance.
You’re right - I should have quit as soon as it was clear it was a death march. But in the shit, I found it almost impossible to lift my head up and say “this is literally killing me, I quit”. When each individual day is at your maximum trauma threshold, it’s hard to work up the time, willpower, or ability to interview prep and change companies.
Thanks for clarifying, and really sorry that you had to go through all of that. As I read, I see that there were many factors at play, some of them personal, some of them cultural -- in my country, the health insurance doesn't depend on employer, for example. But on the other hand, I also saw some people here killing themselves to work, mostly not to let down others.
> We did not have the option of abandoning it, due to a meaningful fraction of the company’s revenue riding on its success. We did not have the option of more resources for the usual reasons. And we did not have the option of more time, because executives had already de facto announced when it would be done.
And immediately concluded that the company has already committed to suicide and it's time to start sending resumes. Cross-team sabotage is icing on the cake but actually doesn't change anything here.
Dunno, I can't speak with certainty that I wouldn't stay and leave, as everything depends on the situation, but switching to a less demanding job and lower pay seems as something that would benefit me in the long run. My mental health and family are worth any price difference, that is, they can't pay me that much to stay in a shitty situation.
In my case, my bozo list is a handful of names that I use to help choose where I will and won't work. If one of these people is at that company, I will decline to accept a position that will subject me to their leadership. Some may see this as arrogant. It certainly assumes I have the privilege of multiple options of employer. It's not generally been my experience that people react badly to this in general, however. I can easily see how it would be much more disruptive when internal to a team.
That said, I have seen whole teams set the bozo bit on other parts of the organization. For example, I saw the head of an infrastructure group refuse to maintain or patch key services while insisting on ownership. The security organization set the bozo bit on this person and worked to protect the organization from the consequences of their choices. As an organizational tool, it can be a useful caution about known bad-faith actors.
As to your broader point, I think you're correct. Programming is difficult, error-prone, and thus benefits from an intellectual humility. Approaching it with the mindset that you are incapable of error makes this much more challenging.
As someone rounding off 20 years in this industry, I'll advise you that it is a _lot_ smaller than you think. Some of the people I've met or worked with early in my career are big names now due to blogging, writing, starting companies, etc.
When I interviewed for my current job, it turned out that I had separate, personal, previous-work-experience connections to all four of my interviewers and it only surfaced during each of the interviews.
And this is after changing my role/specialty.
----
And along these lines, be careful who you shit on in this industry and be default-nice to everyone. I'll never forget one role I had that was fully remote where I was mentoring a guy who was a bit on the weaker side technically for the job that we were doing. Everyone else was constantly telling him that he sucked and was pushing him to quit.
It turns out that he was learning the ropes to transition to a huge leadership role in the company and no one knew it. He had previously led an entire division of a massive computer manufacturer, but 2008 wiped out most of his retirement and he had to come back to work. The very first thing that he did with his new responsibility once his role was announced was to give me a huge promotion to work directly under him with no interview.
There are parts of
our vast industry that aren’t as large, and the “premier” places to work at are only a few big names. Embedded systems comes to mind for me here as does something like chipset design or telecommunications infrastructure, just to name a few examples I can think of
All complex rewarding software jobs but it’s not the same as say, web development, in terms of choices and volume
> How can a handful of names across an entire industry meaningfully affect your career choice?
I've found myself approached by recruiters for the exact large company and sizable department that one of these people has substantial rank in. It's already had an impact on my decisions.
>It combines the bad parts of an ad hominem attack with the bad parts of personal arrogance and negativity. Don't think your other teammates won't realize you've "blocked" a teammate. Some of them will react badly, and potentially see you as arrogant.
You are saying this as a senior engineer who is in a better position to do something else about being on the receiving end of those personal attacks. I respect that and I hope you are able to keep doing it. But that isn't the case when the abuse is continuing over a long period of time, that means no other senior person stepped up to do anything about it, and the people on the receiving either have to quit, or risk getting fired for "insubordination" because they filed a complaint against a senior employee. Playing the office politics game and trying to avoid the abusive employee is not sustainable, as you've acknowledged.
I was mildly troubled by the comment towards the end, "There were third- and fourth-generation members who I had no idea about who had signed up to talk about reliability without being second-guessed to death and hounded by people who just wanted to talk about [...] "a lot of work went into that"."
I've been sensitized, I guess. Yes, the way we do things is probably stupid. Yes, your favorite new framework or method or language or whatever might trivially fix all the problems that you can see. Heck, you might even be the smartest person in the room. But, there might also be a reason things things are stuck at a historical, local maximum.
You are absolutely right, and I think the author would agree with you. Sometimes there are strong, compelling reasons that justify not changing things.
Inconveniently, sometimes the reason is "a lot of work went into that".
I think your "rule" makes a good 80/20 rule. I'm only mid-career but at this point I have worked with people that I will never work with again. I would accept code from them but as a team member I would insure that there was an impenetrable wall of management between us.
There is no fixing some people.
They want to believe that a single narrow interpretation of something is right, by their own experience. You cannot change their mind. eg There is no multiple inheritance in Java so you aren't going to use Java.
> There is no fixing some people. They want to believe that a single narrow interpretation of something is right
How would I not be doing the same thing if I looked at other people as needing to be "fixed" any time their thought processes don't work exactly like mine?
People who have different thought processes from me are great! There's plenty to be learned.
People who are Always Right and who believe that anyone who disagrees or sounds like they might be disagreeing is Always Wrong and must be shouted down... those people are not worth fixing. I assume these people are what GP is talking about.
And yes, those people are real. Quite rare, but real, and a major pain in the ass to route around.
Always assume that it is possible for you to be wrong. Even if you think you are not wrong... just consider what the world might look like if you were wrong, and you'll be fine.
I always try to pounce on negative feedback since it might be the sort of thing other people are thinking too but aren't mentioning out of politeness. If you think about things that way, you'll optimize your way to senior engineer real fast.
* i saw in one project shitting only on commits of a certain person, only on a technical basis, even if other commits were worse. i know this because of a real crappy testcommit i did. i did not get the shit the other person got.
* i still think, some swearings even for code are over the line, like linus torvalds retroactive abort of code, for example. We code and build things. many people poor their soul into this. and then other people come around and shit on it.
* people who shit are often very agressive and competent people. so less competent people may on the receiving end quite a bit, for example the guys who built the ubuntu base in that example. is their work doomed or shit? does this mean that they did not work well? are they bad workers or do generate bad results? should they be fired because their workresults do not perform well? can that be a general rule? and this line is not cut through by on-subject-shitters because "be an adult". and this in turn might create toxic culture. just as well as the toxic positivity which only comes more often because it's better understandable by non-it-guys from HR.
but i admit, at least it's another approach. we need more approaches and studies about them.
If The Illiad is to be trusted, open warfare still has plenty of soap opera.
Humans are emotional creatures no matter the context.
You can't change that - all you can do is accept it then learn how to work with emotions (both yours and those of other people).
IMO, the "adults in the room" are usually the people who have deep technical knowledge and have also learned how to regulate their emotions. One without the other gets you nowhere.
> If The Illiad is to be trusted, open warfare still has plenty of soap opera.
During World War II, some Royal Navy battleships turned their anti-aircraft guns on their own torpedo bombers, because they were determined that carriers not get the credit for sinking the Bismark.
I like that, but it probably won't work, as the people that jump in, out of context, are the same ones that scroll to the bottom of the Ts&Cs, and bang on "ACCEPT." That's OK. I've learned the benefit of building a community by example, as opposed to fiat. The people that follow it will be the ones that don't need to read it, and they will provide the example.
I'm an "older" engineer (just turned 59. I really don't give a damn what people think of it. That's one of the benefits of being my age). I have about 40 years of experience in tech; the vast majority, writing software. Sometimes, quite badly.
Also, almost my entire career has been in "shipping" software; not just "writing" it. This has meant that I've always been pretty damn close to the end-user; sometimes, to the point of receiving personal...erm...feedback. Let's call it "feedback." I've also been responsible for delivering complete product, with polish and support. It wasn't "someone else's job" to clean things up. It was my job (it still is -even more so, these days).
I've watched (and caused) some real Jurassic-scale disasters, over the years.
That's one of the reasons I write damn good software, these days. Nothing like being given a bag and a stick, and told to clean up the mess (even if it was someone else's mess), to teach humility and caution.
So, that means that I'm often the guy that says things like "Are you sure you want to do that? I did it once, and it did not end well."
In today's "cargo" culture, that's considered "being negative," or "being timid, and only the bold survive," etc. ad nauseam.
I'm told that I'm "not a team player," or that I'm "harshing the vibe" (I actually made up the second one, but you get the picture).
This is funny, because my entire life has been ferociously dedicated to making difficult things happen. Precisely the opposite of being "too cautious to leave the starting gate." I've always been about "That's a difficult thing, and here are some of the things that might go wrong, along with a bunch we can't foresee. Let's figure out how to do it, anyway. We just need to be careful and circumspect."
That's pretty typical with experienced folks in any profession; not just tech. We often have a lot of callous and scar tissue.
Yes, we can be so timid, that we are too gun-shy to try difficult things, but we are also fairly likely to actually make it happen, if we take on the job.
For myself, I tend to look for "dreamers," who have ideas, and then help them to actually realize their dreams, as opposed to some of these Krakatoa-level explosions that we see happen, because the execution of a perfectly good idea was flawed and ill-considered.
But it tends to work out better, when we guide them through what's needed to participate. Sometimes, their presence is something we want; just not their behavior.
Yeah, though this depends on the size of the channel - in a somewhat similar vein, see how Reddit basically gave up on parts of the netiquette by instead automating parts of it.
I honestly found this completely unreadable. For example (and there are many others), what does this even mean:
> This place hadn't quite ascended to the level of giving outages notable names ("Call the Cops", "Silent Night", "A Tree Did It" being just a few from elsewhere), it remained just "1152" after an associated ticket in a bug tracking system.
She's recently quit a company, and is not naming that company. She's written a few articles about the reasons for her departure, and they're all very opaque. Full of stuff that folks on the inside will understand, that the rest of us can make guesses about. At times, she's pretty explicit that she's writing for her former co-workers, if not to give hope, at least to make them feel seen & heard about experiences they can't talk about.
Facebook is the previous company she quit to this one.
I found myself in yet another tech gig in an attempt to provide reliability to a company that (as it turned out) was about to have its IPO.
There's a big hint as to the name of the company in the post. If you look at companies that are expected to IPO in the very near term, I'm sure you'll figure it out.
Just as some vulnerabilities have names like "Heartbleed" or "Spectre", some incidents leave enough of a mark on the company culture that they are assigned names.
It's easier in a conversation to refer to an outage that was caused by a system called Maya by a descriptive canonical name like "Mayan Apocalypse", than to refer to it as 14351. As companies grow and accumulate more interesting outages, it becomes harder to keep all these magic numbers in your mental cache.
I definitely screwed that one up, and it's slightly different now. I was going for one of those voiceover-y "not having attained X, they went for Y instead" approaches and it fizzled. I think it's because it was too long and because it's text and not an actual voiceover. (If that makes sense.)
I got it, and indeed if you read it at “talking speed” it works ok.
By the way, I also appreciated the post. I’ve been in similar situations in several occasions and never quite figured out how to avoid stigma and bad feelings for stepping on other peoples’ ego. I’ll give your technique a try
Well, being an introvert dork, I'm not the one to lecture others on how to effectively correct others, but, reading this:
> I was talking about infrastructure, and specifically the wobbly mess of shitty "we're gonna run Flask everywhere and call it microservices" that somehow let people accomplish things over the Internet. Absolutely amazing.
If this is how she talks at work, it's unsurprising that people would find the attitude abrasive. (And if this is not how she talks at work, then maybe she could tone down on dramatization a bit? Well, I mean, sure, it's her personal blog so she can say whatever she wants, but still ...)
I assume part of the point of the personal blog is to let loose in a way that she wouldn't at work, yeah. I certainly would understand that; I've supported stacks that I didn't like because that's what the business used and being a professional (IMO) means supporting what the company uses even if you hate the product, when on the clock.
I'm not sure if it's just your style or you perceive my comment as an extension of workplace sexism, but in case it's the latter - if I saw a male engineer ranting about (ex-)coworkers publicly like that, I'd still have thought "Wow this guy sounds like a rockstar."
Seems like there is missing context here. Part of doing your job is communicating changes and explaining your reasoning when needed, "Unbuntu is doomed" doesn't really cover the need for communications. From the story I have no idea why there would be a need to switch form Ubuntu to Fedora - seems like a personal preference choice and that might look like change for the sake of change and no meaningful benefit to someone in a another group. Feeling like there is another side to the story here.
Author is saying that the company already decided they are migrating from Ubuntu to Fedora. That’s not the controversy.
In a Slack channel, someone said “Ubuntu is doomed”. Not because Ubuntu, as a distro, will soon reach end-of-life, but because at $COMPANY, Ubuntu will be replaced by Fedora. That is to say, “Ubuntu is doomed (at $COMPANY)”.
What author is objecting to is people joining the conversation several hours later and expressing unhappiness that someone is predicting the end of Ubuntu everywhere.
But that’s because the new person wasn’t in the conversation, lacks context, and maybe should start by assuming the best intent rather than the worst intent.
It seems to me that this is kind of irrelevant to the point of the post. Also, if you would like more context, there is a first sentence to this post that links the post that explains the context. Specifically:
> What would happen is this: a couple of people would get to talking (on Slack, for that is what they used) about something technical. There might be a topic at hand, like "Ubuntu is doomed", and they'd be hashing it out, figuring out what that meant. Then, invariably, someone would pop in two or three hours later, hit the hated "start thread" button on one of the comments, and would start shitting all over them.
> "OMG why are you hating on Canonical" "Ubuntu is NOT DOOMED"
> And then the people involved would have to walk this person back and say, look friend, Ubuntu at this company is doomed, because the company has decided that everything is moving from flavor X to flavor Y, and all of the flavor Y images are built from Fedora (yeah, I know, ignore that for this story) instead of X's Ubuntu. So once we're done with the migration, Ubuntu at this company is a goner!
