If you're a developer reading this right now, chances are you're an idiot.
That is, chances are you code regularly in a language that should never even have been invented. Or maybe you use the wrong IDE or the wrong text editor or some version control system that can't possibly do the job. Maybe you're dedicated to a programming methodology that never works, or your release cycles are set up all wrong. You might debug your code the wrong way, or you have no idea which optimizations to switch on in your compilers. Whatever it is, all your projects are destined for failure.
By the same token, chances are I'm an idiot, too.
Why are developers so quick to call each other idiots, anyway? Why are they so pigheaded in their beliefs, so quick to take sides and reduce everything to fallacious black-and-white arguments? Check out any developer forum or message board: It won't take long before you'll find some seemingly innocuous thread that has erupted into a full-blown flame war.
The list of hot-button topics is endless: Emacs versus VI. Java versus .Net. C++ versus Java. Eclipse versus NetBeans versus Visual Studio. Perl versus Python versus Ruby. Agile versus waterfall. Django versus Rails. Extreme programming versus Scrum. Git versus Subversion.
You'd be hard-pressed to find a more contentious group outside a "Star Trek" convention. Yet bickering about your favorite sci-fi shows is all in good fun. It's entertainment; it doesn't have any bearing on real life.
For many developers, on the other hand, programming is their livelihood. When decisions about tools and practices become polarized and zealotry takes the place of rational discussion, it not only wastes time, but lowers morale, causes communication breakdowns in other areas, and at its worst threatens the successful completion of critical objectives.
It's grown so bad in the app dev world that groups of developers have taken to issuing "manifestos," as if they were Central American revolutionaries. First there was the Agile Manifesto. Now others are trying to come up with the DevOps Manifesto (though the thought behind that particular revolution seems a little harder to articulate).
In that spirit, I'd like to propose a new manifesto for those developers who are tired of the partisan squabbling, flame wars, name-calling, and finger-pointing. For lack of a better name, I call it the Maturity Manifesto, and it's organized around a few guiding principles:
1. I will reject dogmatic thinking about tools, practices, and processes
If you find yourself returning to certain websites for talking points about why your favorite tool is better than all the others, there's a good chance you don't really understand your favorite tool well enough to argue as fervently as you do. Talking points are a great way to convince developers why they should try a new tool or become expert in one they already know. They are less valuable when a team is evaluating a range of options for a specific, real-world task.
Also, resist the urge to reject a tool based solely on the vendor that supplies it. Your personal vendor preferences (or prejudices) may not actually reflect the best interests of the project.