How to Make Other Developers Hate to Work with You

I agree.

I'd like to add, in my experience some developers firmly (and sometimes loudly, judgementally) join a working environment and espouse best practices they've acquired from a cultural background they've worked in so far. Or read about, or watched a training course about. And they don't know (or care if) they are pushing things which are advertised as "best practice" in some domain or other, but aren't half as universally agreed upon as they think, and aren't half as effective or appropriate as they think in the new job.

My point is: Some "best practices" aren't as universally agreed upon as people think, and people are often thinking in a bubble.

If you're at a new job, and you see a glaring lack of what you've learned is "essential" best practice, I'd urge caution in assuming your new team are ignorant or that your managers are as clueless as you think at first, even if it looks messy and disorganised.

Of course they might be clueless! But it takes time and deep questioning to be sure.

Of course your experience should be brought into each new place you work. You're hired to bring in what you know, not just to fill a seat. By all means talk about your experience, about things you have actually done which worked well, and about what industry leaders are currently talking about.

But if you feel the need to "teach" everyone straight away how to work better, give it time and consider the possibility that people might have given it considerable thought and experience of their own. They might even be familiar with much of what you're talking about, and rejected it or found a different approach. (Or they might not - that's to be discovered.)

I say this because I've seen people turn up and, in effect, try to start fights long before they have spent the time to figure out (a) others in the team are quite experienced and familiar with the same practices but have decided on something else, (b) different industry bubbles actually do have different best practices for similar problems, and (c) they can't see some kinds of development strategy that are in use, because subtlety.

Not before 5 or 10 years.

Patches and fixes have accumulated in response to strange edge case and bugs you wouldn't believe if told.

The organization and the problem space have shifted somewhat over time. A few things could have been done differently in the new environment.

True enough, but it's not just about making anyone happy.

Even thick-skinned people have a hard time with another type of negativity:

"Negativity" doesn't only mean high quality criticism, or pessimism.

It also refers to low quality, demanding, draining, and often competitive and repetitive discussions where critics are full of it.

Sometimes there is also bullying, always talking over, making out that coworkers are stupid, taking credit for others work, not pulling their own weight, trying to trick people, manipulating people to their disadvantage, insinuations, word-twisting and game-playing, that sort of thing.

That sort of negativity is draining. It's negative in an energy and morale sense.

That's not about hurting anyone's feelings, and it's not even about sadness and happiness.

It's just that some ongoing interactions drain everyone's energy without giving much back in exchange.

Everyone does it occasionally. Some people do it a lot - those can destroy a team and a company.

> "Being a negative or critical person does not make one stupid"

It does if you have engineering goals and the _manner_ in which you are being a negative or critical to other people is preventing the team from achieving those goals.

Negativity does not always come with skepticism, by the way:

Some people are negative in the sense that they demoralise others, yet are full of uncritical enthusiasm to use every random idea and technology they hear about. Which may be what is demoralising others :)

It can be done in a way that show massive visible progress and impact. Just have to fill plenty of tickets for doing plenty of changes. Adding new features that are already present, sometimes renaming the file that had them if necessary. Fixing bugs, possibly freshly reintroduced because the existing fix was purposefully ignored or removed.

Do you know that progress report and commit messages don't even have to match what was actually done or committed? The project is your playground.