It's safe to say the software development world is full of opinions about just about anything you can think of. Search on any development topic in any forum, including Reddit, StackOverflow, or Medium, and you'll be likely to find opposing opinions on it, no matter how trivial it may seem. Observing some of these controversies can shed some light on how easily we can be drawn into an argument that lacks substance or meaning beyond our personal preferences, and I certainly don't exclude myself from falling into that.

Here are a few software development topics that have been points of contention for reasons that seem less than entirely rational.

#1: Which IDE to Use

I'll admit the controversy around IDEs has died down considerably since the infamous Vim vs. Emacs flame wars of old. Well, perhaps "died down" is not as accurate a statement as that it has been buried beneath a wealth of other options to what originally appeared to be a binary choice for those who were not inclined to use the notepad app that came with their OS to write code.

Although a lot of the flaming on this topic is more about trolling and having a good laugh, there are those who really appear to feel that using another IDE than the one they favor is some kind of betrayal of, well, someone. The people who wrote Vim or Emacs? Microsoft, because I prefer JetBrains? JetBrains, because I prefer VS Code? All developers? All of humanity?

Come and take choice of all my library and so beguile thy sorrow. ~ William Shakespeare, Titus Andronicus

Settling on an IDE you like is largely a matter of discovering how you like to code and what features help you the most (syntax highlighting, bracket colorization, AI-driven code suggestions, integration with Git, etc.). And in truth, there's a ton of overlap in the most popular IDEs out there, such as VS Code, WebStorm, Atom, Sublime, or Visual Studio (and if I left your favorite out, I meant no slight by it). They all have their strengths and weaknesses, and you're liking one over the others says little about you as a person.

#2: Mac vs. PC

Outside of the charming ads of my youth starring Justin Long and John Hodgeman, which were not a debate at all since they were there to sell Apple products, this long-running controversy has been a head-scratcher. What's the big deal about using one over the other? I've used a Mac for development in the past, and they are great development machines.

When it comes to my own personal investment in computer equipment, I favor the PC. Why? Simply that I can get a laptop that can (potentially) outperform a Macbook Pro for two-thirds of the cost. Look, when my employer is footing the bill, I'll work on whatever hardware they want me to use. But if I have to fork over $2500 for a laptop, I would prefer to get the laptop that offers me the most power and performance.

That being said, I totally get why some people love to write code on Macs. They have a great OS, they run in a Linux environment, and they have a lot of great software. My personal preference might tilt toward PCs but certainly not because I think Macs are bad machines. And if you want to build native mobile apps for the iPhone/iPad, you pretty much have to have a Mac involved at some point in the build process.

Personal preferences aside, the idea that you are supposed to be loyal to one brand over another when it comes to these critical tools for building the software that runs the world is fairly absurd. Go with the one that fits your style, your budget, and does the job best, and forget about whose name is on it.

#3: Tabs vs. Spaces

I only watched one episode of Silicon Valley, but as it turned out, it happened to be the one where Richard breaks up with his girlfriend over this peculiar controversy. Right up to the big moment, they are both contented with each other. But his colleagues have foreshadowed that he will mess things up, and I won't spoil what happens (spoiler alert: he seriously blows things up). An otherwise peaceful relationship between like-minded souls gets trashed over, of all things, tabs or spaces.

This was a funny scene, made all the more humorous by how stupid this whole debate about tabs vs. spaces has been. And frankly, it shouldn't be much of a thing. If you are working solo, then you get to decide which way you prefer to indent your code. Indent it with 10 spaces if you want. If someone wants to fork your repo and doesn't like your 10-space indentation, well, that's why we have Prettier. If you are on a team, then you work with whatever format the team has settled on and stick to it. Because you have far more important hills to die on than insisting that everyone should be using tabs. Or spaces. Or whatever.

#4: If Statements

I was once told by a former manager of mine that my code had "too many conditionals." He did not elaborate on that point even when I asked, and it took me a while to realize the reason for that was that the right answer to the question "How many is the correct number of conditionals?" is "As many as the demanded business logic requires."

This isn't to say that I couldn't have handled those conditionals more gracefully, or simplified the logic to its base conditions more thoroughly. But it was a wake-up call for me to how widespread this belief is that if statements are just bad. As if the ternary operator can handle every case you throw at it and still be readable to other developers. The ternary operator is a useful device if you have two or at most three possibilities to evaluate, but it's extremely unwieldy if you have more than that.

Follow the path of the unsafe, independent thinker. Expose your ideas to the danger of controversy. Speak your mind and fear less the label of "crackpot" than the stigma of conformity. ~ Thomas J. Watson

#5: Commenting Your Code

This one may seem less controversial than the others and I would tend to agree that code conventions trend more heavily toward commenting than not. But there are those who take Robert "Uncle Bob" Martin's advice in his well-known and regarded book Clean Code to such a degree as to discourage any comments at all in favor of naming variables and methods in a way that describes what they do. One should not dismiss Martin's considerable experience and wisdom when it comes to producing clear, well-written code. And there is merit to the idea that you should name things such that their purpose and action are clear, at least wherever possible.

But let's get real for a minute. Would you really prefer calling a method named GetUsersFilteredByNameIdAndPhoneNumberAsync over and over or would you rather call GetUsersFilteredAsync and have the comments explain which parameters you can filter by? I know it's not the best example and naming the arguments well will make that clear enough. But remember, you aren't just writing that code for yourself, you're writing it for the next person who had to work on it. Code comments sometimes just make more sense than not.

There will always be controversies in the development world, but these are a few we might benefit from if they were to fade away into the mists of nuance and reasoned viewpoints. We can always hope, right?