I have over a decade of professional C++ experience, but I don’t call myself a “C++ Programmer.” Am I competent with programming in C++? Yes, very much so. But I refuse to let my skills be pigeon-holed by the language I’ve historically used. Nor should you.

Use the right tool for the job, the saying goes, and software development is no exception. Programming languages, frameworks, and other tools are the subject of religious-caliber debate but they are just means to a greater end. This article is a call to both programmers and their managers: a good programmer cannot be summed up by the list of tools they use.

The Toolbox

John K. Ousterhout, in this highly-recommended article, splits programming languages into two very rough categories: systems languages (C, Java, etc.) and scripting languages (Perl, Ruby, etc.). Even from the simplistic metric of “machine instructions per line of code” it should be obvious that some tasks are best suited for a systems language and others for a scripting language. Device drivers need to be very fast and very efficient. It’s worth writing them in C, and doing so in any other language would be painful anyway. C is simply the tool for the job. (Or C++ if you know what you’re doing.)

How about a web interface for a database? The job is largely one of connections and business logic: take data in, apply rules and transformations to it, spit data back out. Scripting languages are great at that. They have all kinds of features for data manipulation and they’re easy to interface with external resources.

There are other axes besides “instructions per line of code.” Objective CAML is nearly as fast as C, for example, yet it’s a completely different beast. Factors such as approaching problems in the functional vs. imperative style can be significant to both developer and machine efficiency. Another huge factor is libraries, e.g. part of Perl’s popularity is rooted in its huge archive of modules.

Use the Right Tool for the Job

Any programmer that’s earned their stripes has seen it: the massive C++ (or whatever) application that could have been written in ¹⁄₁₀₀ the lines of code in Ruby (or whatever). It would have been much easier to create, work just as well in production, and be easier to maintain. But early in the game a C++ programmer was faced with starting the application, so he started writing it in, needless to say, C++.

Foolish consistency is the hobgoblin of small minds.
– Ralph Waldo Emerson

The talented programmer has more than one tool in the toolbox. Just as a carpenter doesn’t build a house using only a hammer, a programmer doesn’t need to bludgeon every problem into submission with C++. Use the right tool for the job. Before starting a project, step back and consider: what’s the most efficient way to solve this problem? And what’s the right tool?

A programmer is more hindered than the carpenter in choosing their tools, however, because their coworkers must be able to maintain the code. They may need to find one systems language and one scripting language the team can agree on. That said, it sometimes takes a maverick to force the issue – rather than just causing trouble by developing a project in Python instead of the management-approved language, the maverick may be doing everyone a favor in the long run.

The Programmer’s Responsibility

In school there’s a good chance you were educated in the popular systems programming language of the day: assembly, Pascal, C, C++, now Java. If you’ve been out of school more than ten years, chances are that language is starting to look a little… antiquated. Whose responsibility is it to keep your toolbox current?

It’s up to you, of course. Your current job might be writing C with Win32 APIs, and you’re worried that you’ll need to know .NET for your next job. So learn it. Convince your company to learn it on their time, or learn it on your own, but get it done. Your professional growth is a longer-term issue than the current project you’re working on – and much more important (to you).

But more important than specific tools are the principles behind writing great software. Seminal tomes on software like Design Patterns aren’t about a language or framework, but about principles of writing great software. Don’t just learn Java, learn object-oriented design. Or screw learning something just for your résumé, learn functional programming and gain insight into whole new ways of approaching problems.

Employers Are Not Helping

“Okay, this is all fine and dandy in principle,” you say, “but all the job listings are for [insert language here] programmers.” I admit it’s a rare job listing which seeks a great programmer. Most managers advertise jobs for assembly-line tool operators. Many still don’t appreciate that creating software is a creative endeavor, not a manufacturing process.

The average manager appears to choose their job requirements based solely on what tools have been used before. Even for new products, if the past product was written in C++, the new product will be written in C++. Therefore, hire more C++ programmers. Even for completely new companies, I’ve seen managers with little or no software background choose their technologies before hiring a programmer.

The smarter manager realizes a few things: first, a great programmer is a craftsman who creates software using the best practices and tools for the problem; he doesn’t just turn the C++ crank until enough code units have popped out. Second, one great programmer is way more productive than several mediocre ones. And more than just raw productivity:

The real trouble with using a lot of mediocre programmers instead of a couple of good ones is that no matter how long they work, they never produce something as good as what the great programmers can produce.
–Joel Spolsky

Some managers have gotten clever and turned the “tool operator” problem on its head: it can be argued that advertising for esoteric languages can bring in smarter programmers. It’s not so much important that a programmer know esoteric languages, it’s important that they care enough to learn stuff out of the mainstream. The great programmer is compelled to master their craft with self-education beyond the obvious résumé fodder.

And This Brings Us Back To…

Do you, the programmer, want to be a craftsman or a tool operator? If you’re skilled with Java and your Java programming job pays well, that’s great, but do you want that to be limit of your skills?

I encourage programmers to master their craft. Learn more sophisticated (or simple!) concepts you can apply to the tools you use. Learn new tools. Learn tools that open up whole new ways of creating software. Even if you continue using the same tools at your day job, expanding your perspective on programming will help you create software more skillfully.

And do you, the manager, really want to hire a bunch of tool operators? Perhaps your job is to create boring software that nobody really cares about anyway, so sure, hire some cheap guys and let them turn the crank. But if you can’t afford to create mediocre products, you can’t afford to staff up with mediocre programmers. Put out a bold job post: “I want freaking great programmers.” Enough already with the “7-8 years of C++/STL/MFC/blah/blah experience.” Or be clever and post jobs for Python or Ruby programmers.

The software industry is doing everyone a disservice by defining programmers with a laundry list of tools instead of deeper skills. Programmers need to be diligent about developing a breadth of skills, and marketing themselves appropriately. Managers, in turn, need to appreciate programming as a creative endeavor and seek talented programmers, then let them pick the best tools. Even if you’re hiring for an in-progress project, a great programmer can learn a new tool faster than a mediocre programmer can become great.