In one sense, developers aren’t that different from modern-day carpenters. By and large, both vocations involve working with some basic materials to build larger structures. While there are certainly still artisans—of both the physical and digital variety—who build everything from scratch, the majority of carpenters and developers alike use prebuilt pieces in their work. Both vocations also have a particular set of tools they use to join those pieces into larger structures. For carpenters, this might be a hammer and a saw; for developers, a programming language or set of complementary languages.

That’s what a programming language amounts to at its most basic level: a tool. A hammer used to join various other prebuilt pieces into a new structure. Of course, you want to use the right tool to join those pieces. You wouldn’t use a sledgehammer to drive screws into drywall, right?

Finding the best tool
But how do you determine the best tool for the job? Clearly, you have to analyze what’s available to you (is there a screwdriver here?); you must have some knowledge of the type of problem you’re facing (is there a stud behind this part of the wall?); and you have to know something about the prefabricated bits you are using (is this a Phillips or slot-head screw?). That’s why this habit some developers have of declaring their tool of choice to be somehow universally better than others, or insisting that some other tool is universally inferior, often prevents them from doing the best work they can.

Don’t get me wrong. Pride in the tool you use is important, if not essential, to your work, whether you be a carpenter or a developer. But when you refuse to accept that another language may have an advantage over your chosen language, or you begin to look down your nose at the users of another language, you begin to have a problem. With those blinders on, you can’t objectively analyze what’s available. You begin driving screws with a sledgehammer.

Keeping up with the rapid pace of change in our industry requires a nimble mind and an ability to anticipate the next big thing. It’s inevitable that language X will eventually be superceded by language Y because it allows a developer to be more productive at activity Z. Becoming a programming polyglot is necessary for the success of your career, as is the oft-espoused mantra of learning and applying sound principles. With that in mind, how can you expect to expand your professional knowledge, keep yourself employable, and continue to buy yourself all those neat gadgets if you refuse to believe that there may be something better than what you already use?

A single-minded devotion to a single language, trying to make it one-size-fits-all, and denigrating those who take a different path—these are all prescriptions for professional disaster. After all, to adapt an old adage, if your only tool is a sledgehammer, every problem is going to look like a sledge.

Tell us what you think

Is language bigotry a problem? What are the causes, and what are good ways to work around it? Send the editors an e-mail.