If you haven’t seen the HBO show "Silicon Valley," it’s worth the time. Along with many jabs at well-known tech companies, it’s surprisingly accurate with regard to how IT and developers think and behave. It’s not perfect, but I can’t recall ever hearing a vim-versus-emacs debate in a popular television show. (Can you?)
That same episode used an argument of spaces versus tabs in source code as a plot device. I’m sure most people watching the show weren’t entirely sure what that meant, but it was carried off well enough to make clear it was a big problem. Frankly, to many developers, it is a big problem and has been for quite some time. Truly, however, vim versus emacs is a much holier war.
Besides the obvious “neato” factor of deep techie culture surfacing in a mass-market television show, there’s a bigger point to be made. The parody serves to underscore that some problems we face have multiple right answers, and we often waste an awful lot of energy in pointless debates. Also, it’s best to have a development style guide if possible, so at least there’s a standard arbiter of such issues.
Some aspects of IT have only one right answer: the right route in a core switch, for example, or the right entry in an ACL that makes everything work. But in other places, the rules aren’t so binary. A great example is naming, of every variety: naming of servers, storage, networks, variables in source code, fields in databases, keys in arrays.
I’ve seen people almost come to blows over whether a database column should be named cust_id or customer_id. We all know the developer who commits a ton of changes that subtly alter variable names to better suit themselves. One might think there’s enough frustration to be had in software development without adding to the pile, but to many people, these things matter. Truthfully, they do matter.
As one enters the world of IT or software development, the conventions that you learn on your own or are taught by others become your anchors. As much of this world is invisible, these anchors can be our only guides along a blind path. As we progress through years of study and experience, we push those anchors deeper and deeper, while adding new anchors as we encounter new technologies and new methods for completing tasks. We have built reflexes over many years that become indispensable parts of our overall technology navigation system. When someone challenges those anchors, it’s only natural that we push back.
On the other side, the person challenging those anchors has a set of anchors all their own, built from their experiences. They’re equally as necessary and probably equally as deep. This doesn’t necessarily make them wrong, only different. This is how we get the schisms in tech: tabs and spaces, vim and emacs, and whether CamelCase is or is not the work of the devil.
At times, I’ve encountered others with approaches and methods that contradict my internalized foundations, and I've learned it’s generally best to try to accommodate them. On occasion, I’ve altered my own notions because I recognized there were benefits to doing so, as presented by new thinking or technologies. Other times, I’ve dispensed with them after a period of contemplation. Now and again, I’ve even won a few battles and brought folks back to the path of righteousness.
The important point is that even though we may be absolutely certain we are right about an issue, we cannot discount the fact that others might be equally right about the same topic* -- and ultimately it may not matter. There are enough real battles to be fought.
* This exempts vim versus emacs. Clearly, vim is superior.