multipart-mixed

Why I'm Not a [Insert Language Here] Programmer

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 1/100 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.

Comments

I'm a Ruby on Rails programmer, possibly a Ruby programmer too. I know plenty of other programming languages which I also have a fair bit of professional experience with. But, I'm a Ruby on Rails programmer. Also, I always use the right tool for the job — the thing is, if Ruby on Rails doesn't suit the job, then I don't want to do it at all. I like to have fun when I work, and Ruby on Rails allows me to do just that, most other programming languages do not (at least, not without being very frustrating once in a while).

So sure, always use the right tool for the job. But also, pick your jobs with care. Why waste time with boring or horrible ones when you can be having fun instead? You DON'T have to do them all.

Oh, and I'm self-employed. So I decide.

Tomas, that's a good point, we all have our favorite hammers. :) In hindsight this article is most relevant to salaried programmers who don't always get to pick their projects. I currently gravitate towards Ruby, too, but there are components of my current project which are tiny embedded systems so I'm glad I can flip back to C/C++ as needed.

I work at in an academic lab with lots of really smart people. We do mostly Windows programming and I'm amazed by the depth of knowledge that they have about Windows. On the other hand, I've amazed the group a couple of times by whipping up a quick parsing routine in Perl for a task that would be daunting in C++. Perl is kind of my secret weapon for parsing tasks. I wish that there were an easy way to integrate Perl inline into C#. .NET has hashes and regular expressions, but it doesn't have the natural feel that Perl has for that sort of thing.

An ideal tool should be powerful enough to handle everyday programming tasks and provides the most direct route from taught to code while exerting the least amount of effort. The resulting program should also be stable and maintainable. You already got it when you felt it (when the feeling with the tool is just right).

Nice post. I work in a unix environment, and use perl for damn near everything. The reason is that it is so versatile, and I am so comfortable with it, I can wrap it around just about any problem I encounter (instead of the other way around).

I looked at Ruby. Even wrote a few utilities in it. But in the end, I couldn't see any benefit in switching.

Off the point I suppose, but you made me think about why I tend to pick the tool I tend to pick. Perl isn't so much a hammer as it is a tool kit.

And yes, writing clear perl is easy. Coding standards are everyone's friend.

Cheers.

Much along the lines with what Tomas has stated, I have many languages and skills under my belt after 15 years professionally as a Software Engineer, but that being said.. I program almost entirely in Python centric environments as I enjoy my art and being self employed I get to choose what jobs I do and don't want. Having experience allows me certain flexibility when pitching ideas and/or deciding for a prospective client and their situation.

Sometimes, the big clients dictate the language they want. One of my recent clients requested that I write their point of sale returns system entirely in Python for distribution and real time use at all registers throughout their 400 stores in the United States. This was Burlington Coat Factory, and coincidentally, this was a lot of fun for me as I got paid quite well to code an interesting project in my preferred language du jour.

Excellent post - mostly for its single, consistent theme and the simple presentation. Quite effective in thrusting your point forth. Unfortunately, it will take collective effort at the same time by industry stalwarts to start following such esthetic recruiting and engineering (pun intended!) methodologies. Hope that happens before the place is overrun with idiots.

"I looked at Ruby. Even wrote a few utilities in it. But in the end, I couldn't see any benefit in switching."

Readability and Mainainability.

Perl is ugly dinosaur language.

I am a Ruby writer, and I disagree with using the right tool for the right job (one exception I make for speed reason but other than that a higher language is always better than a lower language)

I am glad we have python. Both python and ruby are good alternatives over the ugly perl dinosaur coders.

Yeah, right tool for the right job. Right all the way. People who don't understand this will either end up writing ugly code in the wrong language or getting a team with just XYZ language, and even end up using language to language compilers! They think XYZ language is the world, and the end of the world. Full stop.

Stop Perl bashing, it's old. I'm not a Perl developer, I'm a web designer/PHP developer/Python hobbyist. But Perl has something Ruby can only dream of: CPAN. You can bash Perl all you want, but it's being used more widely every year. It just doesn't have hype like Ruby since it's been at it so long.

I'm a web developer so I have to use a lot of different tools; CSS, JavaScript, SQL, C#, VB.NET, HTML, PhotoShop, After Effects (can't ignore online video).

Tomas, good point but it might be worth broadening your horizons to, say, Smalltalk/Seaside....

There is a typo in your stylesheet which invalidates it. Remove the comma after entry-more-link and it will validate.

.entry-excerpt,
.entry-body,
.entry-more-link,
{
clear: left;
}

Post a comment