Stop fighting holy wars
Tags: technology
Published: 2021-01-04 15:18:05

---
title: Stop fighting holy wars
published: true
date: 2020-07-31 11:37:55 UTC
tags: #technology 
canonical_url: https://glennstovall.com/stop-fighting-holy-wars/
---

There are many “holy wars” in tech, and you’d be best served to stop participating in them. These discussions are bikeshedding: Spending an outsized amount of time and energy on trivial details. And when talking in public, they don’t paint you in a good light.

In sport, they can be fun. However, I think getting involved in them, especially in public online spaces, can be detrimental to your career.

The developers that spend time talking about these issues are not the developers that get the opportunities to work in a higher context. As Patrick MacKenzie says, [don’t call yourself a programmer](https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/).

Here’s a list of conversations you should avoid, both online and offline.

## The Ban List 

####  Is HTML/CSS/SQL “coding”? 

Yes. They are all Turing complete. It doesn’t matter if they aren’t. Instead of focusing on what “real coding” is, focus on how people use tools to solve problems. Excel isn’t “coding” but there are sheets out in the wild worth millions.

#### Is Frontend or backend more difficult? 

This isn’t a video game, and you don’t get points for playing on a higher difficulty level. Backend developers have to think more about scalability and security, while developers on the front lines have to work in the wild west that is every conceivable browser and phone.

#### **Tabs vs. Spaces** 

The “oxford comma” of software development. Most text editors and IDEs can abstract this away from you. Get your team to agree on something, and stick with it.  “What I prefer tabs but the rest of the team prefers spaces?” Then you use spaces.

####   
**snake\_case vs. camelCase**   

Same as above. These are the types of syntactic decisions that don’t affect readability or maintainability. As long as everyone agrees, either one is _fine. _

#### when to squash and rebase commits

I’ve honestly looked at a git history maybe half a dozen times in my career. So long as the code works and is delivering value, I have no interest in the structure of that code’s origin story. 

#### **Vim vs. Emacs**

Use whatever tools you are most comfortable with, and let others do the same in peace.

#### My Framework/Language/OS of choice is better than yours.

Do not identify with a technology choice. Frameworks come into fashion and fall out. Like code editors, use what you like and allow others to do so in peace.

#### **That Framework/Language/OS is garbage! Why would anyone use that?** 

A more negative framing of the issue above. JavaScript, WordPress, and PHP are the most common targets. Why do people still use these tools if they are so poor? Because they get the job done. Let the people using these tools continue to get the job done. 

#### “Rails is dead”

The shortage of COBOL developers in 2020 proves that no technology is ever truly dead. Tell Airbnb, Shopify, Twitch, and Github that Rails is dead. A language’s popularity does not correlate to its quality. People still use Rails (and COBOL) because it gets the job done. 

## What to do Instead

I would make an exception if someone, especially someone more junior asks about these in good faith. On Reddit, Twitter, with random people is not the place to debate. It’s rare that you’ll actually change anyone’s mind on one of these issues. In the worse cases, you’re tearing someone else’s work and worldview down. Treat these conversations as profane. When you see them, walk away. 

Instead of trying to persuade people, invest time in teaching them.  
Instead of tearing other people and tools down, build other people up. Go give a shoutout to a manager about a co-worker, or tweet an article you found interesting.

And if you have a suggestion for another argument I should add to the banned list?

The post [Stop fighting holy wars](https://glennstovall.com/stop-fighting-holy-wars/) appeared first on [Glenn Stovall](https://glennstovall.com).