A recruiter asks "What exactly does a Drupal Developer do?"

Over on the "Drupal Developers" group at LinkedIn, a recruiter asked the timeless question, "What exactly does a Drupal Developer do?"

YES! I was SO excited that I dashed of this mini [or NOT so mini] essay as a response. BUT it wouldn't fit in LinkedIn's character limitations so I'm creating a blog post about it instead. :-)

I WILL ADMIT from the outset that this is a tad simplified for the benefit of our recruiter friend. I know that there is some room for debate on what a DEVELOPER does and where the lines are drawn on UX, UI, Module confiuration, Module building, etc. But regardless of all of that, I believe what I have here is a pretty honest and accurate depiction of a very common scenario that is played out daily with regard to how DRUPAL is getting done by the masses.

I can't tell you how happy I am that a recruiter has asked this question. I get phone calls, emails, webform submissions, LinkedIn messages, etc from recruiters at least 2 to 5 times a month. It is SO clear to me that that the recruiter never understands what a Drupal Developer does. The best they can imagine is to think that we are like .net developers where you throw  4 to 14 of us in a room and hand out lots of web development specs and watch the code files quickly build up on a server. [not the way we do it, by the way..]

What exactly does a Drupal Developer do?

Let's start by defining "DEVELOPER" first as a "SITE BUILDER."   
Here I go!

A Drupal "DEVELOPER" will take either a fresh Drupal install or one of the many Drupal Distributions and mold it into exactly what the client [boss, organization, stakeholders, etc.] needs. Does the project need polls or blogs or a way for users to submit product reviews? Maybe the site keeps track of pending legislation in state or federal government and allows users to discuss the legislation within categorized groups. Perhaps the site has memberships where some are free but there are also 3 levels of paid memberships; each with different kinds of access. ALL these details need to be ironed out, then you bring in one [or more] Drupal developers to use the configuration pages of Drupal to build out this functionality. 

In many cases you can get ALL of this done by clicking and dragging, and dropping and saving forms within Drupal. A skilled Drupal "DEVELOPER" knows which modules to use to bring in functionalities "X" and "Y" and "Z." OR they know how to find the module if they have not previously used it before. 

Configuring these modules together to make the site DO what the client needs done.... That is the beginning of a Drupal "DEVELOPERS" job. We liken this to framing out a house. Before we can start choosing flooring, wall types, colors, and materials, we need to know how big each room is AND how rooms are connected AND how you get there. In the same way... When I build your website I need to know about your content. What is it? What data and what kinds of data might a user see on any given page? How does data change from page to page or from user to user? Does this site interact with any 3rd party sites as in checking for press releases OR checking stock data OR pulling twitter or facebook or LinkedIn info? What happens to the data pulled in? How is it presented to users? What can users do with it? IF all those questions are answered, then a Drupal "DEVELOPER" can build the site to DO and PERFORM all of those tasks.

I mentioned that in MANY cases all this can be done with Drupal's amazing, built in configurations pages, commonly called the "back-end." Sometime's the old adage "There's a module for that" just isn't correct. When this happens a Drupal "DEVELOPER" must also be a CODER or, more commonly, you may have a couple site-builders and a couple coders on the same project. The reason for the CODER is that we need Drupal to do something that either {A} is VERY specific to this client and project and/or {B} the default way Drupal does something [or some things] is not exactly the way the specs call for. In these situations, it may be true that a Drupal "DEVELOPER" will need to write a module that may be a whopping 12 lines long OR it could stretch into a series of modules that interact with each other. This all depends on a combination of WHAT the client needs built and HOW MUCH they are willing to spend on customizing the workflow to get EXACTLY what they want. Drupal will DO exactly what is needed. The question is {A} does the Drupal "DEVELOPER" know how to make Drupal do that and {B} Does the client want to spend a day or two on discovery and another couple days for development followed by some testing and tweaking time? Budget strapped projects are extremely happy that Drupal's back-end rocketed them to the point that 95% of the requirements were accomplished in such a short time. But tweaking that last 5% takes a good Drupal "DEVELOPER" and some available time/money to build it out.

There you have it! A LONG WINDED but still SHORT explanation of what a Drupal "DEVELOPER" does.

I didn't say a single word up there about Drupal THEMING which is where we take this fully functional site and make it look EXACTLY like the pretty pictures that the designer created. That's a WHOLE different skill set. I know a FEW ppl who can do it all and trust me…. You and you're client can't afford those people! ;-)