I feel differently today than in the past about many of the things I've seen technical people argue about. I've written about Tabs vs. Spaces and Singular vs. Plural, and others have debated commas before or after among other topics. While these might be interesting sidebars at lunch, I see them sometimes devolve into time sinks with teams revisiting the issues over and over during their daily work.

These types of religious wars stifle a lot of productivity and often can linger for years. However, in many cases what I see is debate across weeks or months and then time spent to shift the way that large groups of people work inside of a company. In the last few years, I've seen customers argue about which VCS to use, which new CI tool to choose, or even about which secret store to use for their database credentials. Often these debates happen when there is already a technology in use.

In most cases, the differences between many of these arguments are negligible. Lots of teams fall down on either side of a debate and find themselves very productive. Or not productive, but it often seems the difference is the staff, not the tool, platform, language, or style. Good people are productive no matter which way we choose to work.

My view is that for most of these items, we ought to have a (relatively) short meeting. Give each side a few days to prepare, but then one spokesperson for each side gets 5 minutes to present their case on why the group should adopt their idea. Once everyone has presented, we debate for a limited time, maybe 15-20 minutes, vote, and then move in that direction. Ultimately, we're trying to get software written (or deployed or managed or something) and not trying to decide the best way to format that code or choose a tool for CI/CD.

This teaches people to communicate and learn to present a rational, coherent, succinct idea, which is a valuable skill. This also teaches us to work as a team and learn to accept decisions that don't go our way. None of us wins 100% of the time in life, so make a good effort to lead others in your direction, but accept that they might choose a different path. In that case, learn to support the team in their efforts.

The caveat to all of this is that inside of an organization, we often want a standard, so if something is already heavily used, just adopt that pattern or technology.