Over the course of our search for new developers for WorkHabit, I’ve often gotten a letter or message from Drupal Zealots large and small — Drupal developers that were born and indoctrinated into the community and believe it’s the best thing since sliced bread.

And rightfully so. Drupal satisfies the technical requirements for a vast number of problems surrounding social software. There is, however, a delineating line between where Drupal leaves off and where other applications or programming languages may do things better.

People ask me what I do. I tell them I’m a Software Engineer. I’m not a web developer, nor a php developer, and most certainly not a Drupal developer.

Granted, I’d like to think I know Drupal extremely well. I’ve delved into the realm that is node structures; I’ve programmed views filters, submitted patches, even written modules from scratch — all of these things you must do regularly to consider yourself someone who can develop in Drupal.

But why do I not consider myself a Drupal developer?

Because the sign of a good Engineer is someone who doesn’t care about the technology. Drupal is a great tech, but it’s not the only one out there. I may use Drupal for the front-end of an ecommerce application, but that’s because (with the addition of a couple of modules), it’s good at it.

I’m not going to use it for batch-processing tens of thousands of customer records however. I have Jasper Reports and Java for that, again, also good at what they do, but for different reasons.

Open-source movements have a tendency to pigeonhole developers into finding a one-size-fits-all solution, and that can lead to some incredible problem solving, and some equally hefty spaghetti code.

What marks the measure of a developer versus an engineer is someone who doesn’t limit themselves, someone who keeps learning, and someone who isn’t afraid to ask themselves regularly “is there a better way?”

I’ve heard it constantly over the years: one persons insists that Linux is the best OS here, PHP is the best programming language over there, and occasionally you’ll get the Rails or Postgres zealot. The bottom line: Does it really matter?

Let me break it down by using a baseball metaphor.

Those who know me know that I’m a big San Francisco Giants fan. I meet other fans occasionally while I’m out and about, and they look at me wearing my Giants hat and give me a high-five.

At the same time as I love the Giants, I also love baseball as a whole. I go to Athletics games, I go to games for the Sacramento Rivercats (a minor league team). A day with baseball is better than a day without.

So if the Giants aren’t doing so hot, I don’t freak out. I don’t stress it. They may do better tomorrow. And even if they don’t, I saw the game, I rooted for a team I like, and if they lost, it’s still baseball.

So my point with this? It’s not about the team. It’s about the sport. With software? It’s about the solution, not about the technology. An elegant solution is not worth anything unless it does what the business intended it to do.

I’m happy to talk technology. I’ll compare the intricacies of deploying a rails app with you; in as much as I’ll bemoan the difficulties in doing the same with Drupal. I’ll talk about PHP’s threading model (or, in most cases, lack thereof) while heralding the simplicity of doing the same task in Java, and bemoaning Java’s inability to deliver a simple RSS feed without importing 3 libraries and writing a servlet.

But you will never hear me say “Framework X is the coolest thing. Period!” no matter what framework X is.

That’s what separates a developer or programmer from a consultant or engineer.. Don’t pigeonhole yourselves, people! Make decisions that bring your thinking outside the box. Make decisions that simplify your work, your life, and make a better product.

It’s not about the tech. It’s not about the community for a specific tech. It’s about getting results.