[KronisLV]

> Fear of conflict: seeking artificial harmony over constructive passionate debate

What do you do when you don't fear the "conflict" (passionate argumentation in search of better approaches) but having it leads nowhere, because people have different opinions?

For example, I responded to a comment where a person had a difficult situation with a coworker, though I didn't really have any solutions myself either: https://news.ycombinator.com/item?id=41601023

There's a lot of abstract stuff out there, without always having a clear cut "best" answer, but which will have different drawbacks long term, which will impact people differently (e.g. in regards to webdev, that could be using an ORM vs not using it from a type of workload where either could suffice, composition vs inheritance, DB views vs dynamically built queries in the app, using the DTO pattern vs not, using projections for returning DTO data directly from the DB to avoid needing arguably unnecessary mapping in the app code between an Entity and DTO object).

Probably there's dozens of things like that, that apply to game development as well, with people whose opinions have been shaped by differing experiences.

I think that you will probably need to compromise a lot and with outcomes that might feel sub-optimal, hopefully without souring the team dynamics in the process.

[rcxdude]

You need to have a way of resolving conflicts independent of arriving at a consensus (which is usually the best way to do things when it's possible). Usually in technical projects this is done by escalating up the chain of technical management. It could also be done by some kind of voting process, but this isn't very common except in some larger open-source projects. It also requires that the members of team will accept the decision, and not actively work against it. If you have a team member who will not accept things done any way but their way, then they're probably someone you don't want on your team.

[dwattttt]

A phrase I heard early in my career from a superior while reviewing code was "just reminding myself that while this isn't how I'd do it, that doesn't make it wrong"

[KronisLV]

I don’t disagree with the take, but it doesn’t seem sufficient either.

Even if you have developers that know better than to toss aside each other's linter rules and don’t rewrite each other's code in the name of “refactoring”, then if you still have people with differing views working on the codebase, its consistency over time will become less than more.

Whereas if developer A tries to be agreeable then more and more of the code will be written in the way of how developer B wants it to be written and that might make developer A’s life harder over time.