No. no. no. Absolutely not the sign of a pro-developer. A pro-developer is often the most vocal about which languages to use.

A Pro-Developer Has Failed Before

True knowledge of the strengths and weaknesses of a programming language comes from failure, and not text books or user manuals on how to write in that language.

I’ve worked on a wide range of projects that have failed. People were fired and businesses lost money. The programming language used played a role in what happen, and I’ve learned a lot about the risks involved when using that language.

Success Alone Is Not Enough

A developer can be certified by a credible organization for a programming language. He/she may read books extensively on a nightly basis. They may have several open-source projects they publish in that language.

Being successful in a programming language doesn’t give you the wisdom to avoid problems. It makes you overconfident, and I’ve worked on many projects where the lead developer was overly successful. As a result, they wouldn’t listen when trying to voice caution that the team was headed for problems.

What’s The Sign Of A Pro-Developer?

Fear when presented with the opportunity to join a project that is using the wrong tool for the job. The developer who shows signs of ignorance or calm is an inexperienced fool.

Reverse Evaluation: I assume we’re talking in terms of a job interview. How to tell if a developer knows his stuff. A pro-developer will turn the tables in an interview when he detects a mismatch between the problems at hand, and the programming language chosen to solve them. He’ll want to know why the interview represents a company that has made what he thinks is an obvious mistake, and he knows changing programming languages is like trying to redirect a huge asteroid headed for New York.

Why Does This Happen So Often?

It’s a multi-phase process. Here’s the short form.

1. A business starts a new project with inexperienced people because they’re cheaper.
2. Inexperienced people pick the programming language they are most comfortable with. Not what is right for the project (often this is done by people who won’t be writing the code).
3. 90% of those projects fail, but 10% survive.
4. Those 10% suddenly need to fix up the project because now it’s selling.
5. Now there is a criticise so they decide to invest in an experienced developer.
6. The experienced developer comes in and demands the programming language be changed (all the other pro-developers interviewed wouldn’t take the job).

He is now thought to be worshipping a particular language and a holy war starts.

This scenario plays out over and over again in industry, and it’s because of this that so many developers debate the pros/cons of each language. We all don’t want to be that guy who has to fight a way to change languages. So these debates can become very heated at the start of a project.

No Turning Back Once You Start

Picking a programming language is like taking the first stab with the shovel into the dirt. You are either planting a tree, or digging your own grave.

A good coder, like any good craftsman, does and should care about his tools.

In answer to point 1. A professional developer should gain a deep knowledge of the tools he is using as far as it is relevant to the task at hand.

In answer to point 2. “Not caring” is perhaps too strong a wording. But unless he or she is specifically tasked with selecting the tooling and programming language, then they should accept the chosen tool set and get on with the job.

Having said that I personally carry a “box of tools” around. Some are programs, scripts, perls, awks of my own devising, some, are freely available tools like gvim, squirrel, SOAPUI.
I often use these in preference to the “official” tool sets purely because they work well, and, improve my productivity.

As for language “wars” any professional should get over this. Depending on the task at hand you will find yourself implementing solutions in a variety of languages. My current task, which is admittedly somewhat weird, involves coding in C#,VBA,COBOL,Rexx and JCL with a little bit of Java thrown in. Whereas its a pleasure to code in C# and a pain to code in COBOL, COBOL is the right tool for that part of the project so there is no point in complaining about it; I just write the best COBOL I can.

“Total ignorance” is not the right thing.

A developer should know about the strengths and weaknesses of his tool: Don’t use a screwdriver to drive a nail into a wall. (And if all you have is a screwdriver, you should at least know that a hammer would be better.)

Fandom, on the other hand, should be avoided. (“I would never touch anything but an ACME hammer!”)

Programming languages are at the heart of programming and a professional programmer can care deeply about them. Nevertheless in lots of cases with mainstream languages the differences are marginal or not fundamental. Therefore for a professional developer these should not be reasons to complain loudly about trivial differences.

However, there are subtle differences between languages and these are real concerns because when switching between them even a professional programmer will end up doing mistakes, just because she/he thinks that C# is really not that different from java, or javascript is ruby with curly braces…

With the programming world becoming more and more polyglot and more and more languages with different concepts being available there is definitely the need to discuss plattforms’ strengths and weaknesses. This is actually more relevant than some “language wars” of the past (C vs. Pascal or C vs. C++ that was a proxy discussion about programming paradigms). Evaluating your tools is professional.

There are sites and examples that are at times bashing certain programming languages. These range from quite negative to “funny awkward things in my favourite programming language”. One way is to view those as negative critique that does not lead anywhere, but in the end they give valuable information on the programming language:

• http://wtfjs.com/ on JavaScript
• http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/

Without thinking about our tool, we cannot be professional. That being said you should be able to work with bad tools as a programmer.

Conclusion: The professional programmer cares about programming languages because she/he cares about tools. Like a car driver she/he has favourites and knows the weaknesses and benefits (and the dangers of a car without Airbags). In the end he will drive them all if necessary or be really cautious (when driving that australian road-train truck).

I like James Anderson’s answer, but I want to look more closely at your interpretation of Zed Shaw’s comments. I don’t think Shaw is saying to be “neutral to languages”. In fact, the only way one doesn’t become “blinded” is to care enough to learn enough to form a positive or negative opinion so that you can choose the best “tool for doing interesting things.”

Given that, in my estimation (as a long time developer and manager of such people) a good coder does care very deeply about tools used and not just the output, because he or she knows enough to be aware of what will work and what will not work for the situation at hand.

Looking at your writer analogy, “like writer does not care about pen he uses – he thinks about the BOOK content”, I would actually make the analogy this way (although believe me, writers care about pens 🙂 ) — a writer wants to put forth a message, and the medium through which he or she does it could be a sonnet, a haiku, a novel, or a song (and so on).

A “pro developer” wants to put forth a solid architecture and an application that scales, that meets the needs of the stakeholders and so on — he or she could do that with Ruby, Python, Java, whatever, and the decision about what is best hopefully comes from a person or team that has the ability and knowledge to take all the factors into consideration.

So, as to your question, “is it a sign of pro developer, if he does not care what language to use?” My answer is that a “pro developer” does care what language is used, has a well-formed opinion about it (as opposed to an answer like “use Ruby because all the cool kids are doing it”), and if needed can roll up their sleeves and do the work even if it means working in Java instead of Ruby (and so on).

However, remember that people who work in places where the language is dictated for them, and are quite good at what they do in that one language, are still very much “pro developers”, but they might be less able to have lengthy discussions about suitability of language for task if they only know the one language. Doesn’t make them less “pro”, just that they wouldn’t be the only people I would have in a room when I’m soliciting thoughts on languages to use for an upcoming application.

All developers should understand the basic precepts of writing clean code as well as (generally speaking here) Object Oriented Programming.

To the extent of knowing the above, then the developer can be confident that he/she can code in any applicable language, and this is a good thing; HOWEVER, being able to code in any language doesn’t necessarily make you a GREAT developer.

As many others on this post have pointed out, GREATNESS comes from understanding the fundamentals BUT ALSO having enough domain knowledge to select the right tool for the right job.

Choosing the right tool for the job is a complex decision and is made from an architectural context that involves the needs of the stake holders, the intended use, the intended audience, key performance metrics, and so forth.

As the developer, it is good to be able to confidently accept the coding task, along with a prescribed language. If you disagree with a prescribed language, then just be able to provide substantive reasons beyond, “because I don’t know that language”.

One thing I have learned about this business is that there is plenty of work out there. You don’t have to take on jobs that are to be executed with tools that make you uncomfortable. At the same time, I personally look forward to the challenge of taking on an unfamiliar language, and I usually learn something new thanks to doing so.

Hope this helps!

Every professional developer should be looking at, and clamouring for, scientific repeatable evidence for or against the multitude of tools and methodologies they use. We need to get away from the “Oh this book says its good so lets bet the project on that” or “we can only hire programmers that know X so lets use X” way of pouring money down the drain on so many projects and try and put some science behind the shouting.