I would say it definitely happens in the professional realm. It isn't quite as heated as online toxicity, but it can cause some similar negative feelings. I think it is all about how software development is almost entirely subjective which leads to difficult conversations.

Software development is subjective because there is no science to it. There is computer science which is the basis of it, but that is more of a mathematical discipline. Modern programming languages are abstractions on top of the 1s and 0s, so anyone is free to create or use a programming language for a program as long as it can be translated to run on a computer. Different developers have different tastes and different types of programs could benefit from different programming language features. It is someone's opinion making that choice, not a well-defined set of rules based in science.

I think that the subjectivity is the root of any elitism in development. Developer A is writing a program a certain way using a particular language, developer B tells them that they shouldn't be writing it that way or using that language. I feel that represents the format of any negative interaction regarding software development, but there is no clear winner.

This manifests itself in the workplace regularly. It may not be hostile like online comments, but it can be difficult to navigate. At times, being a software developer can be more about working with people than working with code. Everyone thinks differently and it can be hard to reach a consensus. When developers cannot work together effectively, it leads to different styles of programming or a mix of tools being used. This negatively impacts the product, the budget, and the overall team morale. One developer could be concerned with getting a task done as quickly as possible with no regard for future problems, another developer might have heard that functional programming is the new hotness and they want to rewrite all the things, and a third developer could be jaded from hastily implemented code or jaded from adopting something that was not the right fit. Combine that that with personalities and emotions, it can quickly turn into a heated discussion over what is best.

To avoid this at work, I recommend a few things:

• Be open to different opinions. What I have done is created a list for "what would it take to change my mind", if someone with a differing opinion can provide something close to that, the conversation goes a lot smoother. If I have an opposing opinion I try to provide that as well.
  1. You can explain your idea clearly in a reasonable amount of time. If I can't understand it, I can't feel confident in it.
  2. It isn't a massive departure from the team's comfort zone or a bombshell idea. We have to implement working features and meet deadlines, sometimes that means sticking with the boring go-to solutions.
  3. There is a reasonable justification for it. If the explanation amounts to "It's better" or "it should be the way I like it", that is not reasonable in my opinion. "It's better because I find it much easier to read code that has consistent spacing and indentation" is much more reasonable. I respect those that I work with and if they do not like something, I want to help make it better for them.
• "Actions speak louder than words" or "be the change you seek" or "an idea that is developed and put into action is more important than an idea that exists only as an idea."
  • Be the person that has an opinion because you see a problem, want to genuinely be helpful, and will follow through on improvements that will help your team. Being an opinionated developer that does nothing but cause conflict by sharing opposing opinions will get you nowhere.
  • If someone is passionate about not using semicolons for a new project in JavaScript and they set up a formatter config and a guide on setting it up, I like that. If they just complain about semicolons every chance they get and do nothing - not a good look.
  • Again, no bombshells. I'm not advocating taking it upon yourself for re-writing an entire codebase, but taking appropriate action on incremental improvements is always welcome in my book.
• If you are an established developer, be a good leader. Good leaders do not dictate how things should be done or stay rooted in old ways. They provide their experience and guidance to other developers but ultimately let the team have the final say. They are there to support and make others around them better, not to force their way of doing things.