Being a Better Programmer #2: Don’t Be a Missionary

I've spoken a great deal thus far about the importance of knowing when black and white thinking is helpful and when it's harmful. For most people, it's easy to make this distinction. Doctors tend to learn what procedures are there for safety and which are there for to protect the higher ups. Police officers know that if they wrote tickets for every offense they saw, they'd be busy as hell and pissing off the people instead of protecting them. Music professors teach the rules of music and then teach the student to ignore them. Yet developers... we are very rigid. There's a right and wrong way to do everything. This thinking gets us very far, but there's a dark side to all this: evangelicalism.

"Patriotism is a kind of religion; it is the egg from which wars are hatched." - Guy de Maupassant

When I was a young programmer, I realized there were a vast number of options out there. I was enthralled by the choices available to me. I can be a Java developer, I can be a Perl developer, I can be a ColdFusion developer. I can be a C++ developer. The options were vast. My mind was a sponge. This didn't last long, however. Soon I found a niche: Allaire's ColdFusion. And it was good for what it did, especially at the time. Easy to learn, clean flow with HTML, and at the time the only other options were ASP and PHP (and possibly Perl with Mason). ASP wasn't really an option for me, PHP was in its infancy, and Mason never really to this day developed as fully as I'd like. To do rapid application development, ColdFusion was great! And so my first tryst with evangelicals began. I became active in CFUGs and started professing the greatness of ColdFusion. And why wouldn't I? I knew little else that could do what I wanted. Then I learned of the raw power Perl presents...

Perl, a shell language turned scripting language, had a level of access to the file system that ColdFusion completely did not at the time. I could read files directly. I could write scripts which would manipulate images. I could write amazingly fast regular expressions. Hell, I could even trick it into working like an Object Oriented Language. Oh and CPAN... drrrooooolllll. So I joined the local Perl Monger's chapter and even hosted the meetings at the lab I worked at during that time. Unfortunately, no one would let me use Perl as much as I'd like because I had locked myself into ColdFusion development.

What's next? What's the point of being an evangelic if no one wants to come with you? I went from Evangelical Perl Monger to Missionary. I began dragging coworkers to meetings, I would talk endlessly about the benefits of using Perl, I would chime in with a, "It'd be easier in Perl," at every opportunity... and people hated me for it.

Was I right? Sometimes yes, but most of the time, no. Just because it's cleaner to do something in Perl does not mean that it's right. Nor does it mean the solution we had was "bad". Yet, I could not see the mountains of code from the solid rocks of practicality.

Why is it that so many programmers stick to one language? Since then I've learned more language, programming models, and development IDE's than I'd care to list. What have I learned from this?

1. The Right Tool For the Job and the Best Tool for the Job are Rarely the Same Tool

Being a good programmer has little to do with what you code in as much as it does with why you code in it. I'm working on a project right now that would benefit most from being in Ruby Rails, but the project manager doesn't understand Rails. He doesn't know why it would help, and he's far more comfortable with PHP as he's dealt with PHP development before. So, say I insisted in using Ruby, I would have to add another level of complexity to this project of trying to convince him it's the best tool for the job. And in doing so, I would also have to convince him PHP is not the right tool for the job.... which is untrue. PHP is the right tool, despite being the best. Why? It does everything the project needs and it makes the project manager comfortable. Who am I to try and convert him? I told him, of course, but he's still uneasy. Being a mature developer means you are able to...

2. Pick your Battles

There's a time and place for your convictions. Missionary programmers are unable to recognize this as they're too busy worrying about their own agenda. Pushing a language is not a noble goal for a project. It's a noble goal for developers. If you are willing to sacrifice your projects for something as ethereal as a language, you're missing the point of being a programmer. Being a programmer has nothing to do with pushing a language or tool. The goal of a programmer is to ...

3. Be Productive, Not Combative

If you're going to develop in a language, you may as well use it to its fullest. It doesn't matte if it's your favorite, nor does it matter that it's the right tool. The point is to help people. I can't underline this enough: The Point Of Being a Developer Is To Help People Not Causes. The perfect example of this are the epic battles between emacs and vi. The most ironic thing about the emacs vs. vi conflict is that these people got nowhere. There was no winner. These very intellegent people were spending so much time arguing over something as trivial as what text editor was better. How ludicrous! Just fantasize if the amount of energy spent arguing over that alone was put into developing some good software... we could have solved the NP-completeness problem!

Ok, maybe I went a bit overboard with that. The point is, to be a good programmer you cannot be a missionary programmer. There is no "right" language. It's not Java, it's not Python, it's not Ruby, it's not C#. It's whatever works for the project. Learning how and when to use the right tools is how one becomes a better programmer.

Collin Cusce is a developer of 10 years and author of the blog: http://humanerr.com