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?

Open Enterprise ADMIN screenLet'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! ;-)

Comments

I'd say we need to distinguish between a Site Builder and Developer. What you describe as a CODER is really the developer and the rest of it is site builder. There is a whole army of site builders out there who are not developers.

Site builder - build functionality via plugging and configuring various modules
Developer - write custom modules
Themer - experts in the theme layer

You could be one of those, all three of those, or two of those.

It is all semantics, but the confusion starts if a "Drupal Developer" doesn't write code, but a developer is any other framework does.

Agree with the above comment a drupal developer writes custom modules, what you are describing is a site builder.

"Drupal Developer" is technically a non-concept. Because Drupal does not have a specific application domain (e.g. .NET is a typical enterprise framework), there is no categorical activity. In contrast to a ".NET Developer", who tends to have a relatively specialized skillset gained from a particular role in an enterprise development team, Drupal development can cover any combination of the following traditional roles:

- Programmer
- Themer
- Frontend developer (i.e. client-side dynamic development)
- Software architect
- Systems architect
- Platform maintainer
- Testing analyst
- Security expert
- Networking engineer
- Business analyst
- Multimedia specialist
- Server administrator
- (... and many more)

To illustrate the point, I'm currently in a job that requires all of the above in my position.

Trying to pinpoint the roles of a Drupal developer can be as ill-defined a task as trying to find a suitable CEO. One needs to: weigh the other skillsets in the team, determine the typical scope of projects undertaken at the workplace, and try not to reduce evaluation to some impractical criteria.

If "Site builders" build functionality via plugging and configuring various modules and if "Developers" write custom modules, how do you call the ones who write code to to plug and configuring various modules in order to build functionality (Features, Strongarm, Views in code, etc.)? You known, the kind of code you write in order to ease deployment of new features on existing websites? I believe the skills set for this is what most medium to large companies are looking for, without being able to name it, when they say they need "(Drupal) Developers".

I agree with you all.

BUT the question here is dealing with recruiters. They are not asking for "site builders" or Module Developers/coders, or Themers by name.
They say meaningless things like "Drupal Developer" thus I had to answer their question no matter how awkwardly worded that question is.

You'll also note that I go to great lengths in the LinkedIn post to draw even MORE distinction AND to assure the recruiters that they will NOT find one person that is awesome in ALL of these areas ANd who also wants to move to their town and take a cublicle job for $17.50/hr

I'm on your side guys. :-) 

Drupal jobs can be dreadfully underpaid...

In any case, in what context did the recruiter ask the question? Recruiters dig into an unfamiliar position description in order to try to expand the applicant pool, but in this case it may very well be a simple predisposition on the part of the recruiter regarding the word "Developer" (leading to a misunderstanding of what a Drupal Developer might do).

It's like trying to explain what a VP (Vice President) in a company does exactly. There is no unqualified answer to that question: one must begin the answer with something like "In our organization" or "Depending on the department in question". Though we know a VP typically leads a team of an unspecified size at an undetermined level of seniority, a recruiter knows to ask questions like what specific responsibilities the VP will have instead of "what does a VP do".

I explain this to recruiters several times each week like this: within the Drupal community, what the outside world (ie: a potential client) calls a "developer" is divided into three roles, which we call Builders, Themers, and Developers. (We also have Designers and System Administrators, but the outside world understands those roles.) Generally, the work a client is looking to have taken care of is primarily the domain of Builders and Themers -- you bring a Developer in if the pieces you have to work with can't get the job done.

A good metaphor might be how people seek medical services. The Builder is a GP: you consult them first, you talk with them the most, and they generally manage the other pieces. Developers are specialists, like a surgeon: they're highly skilled and expensive; you want them when you need them, but you want to minimize your exposure to them or you'll run out of money. So in this view, a Themer is like a nurse? You almost always need them, and they make you feel better about the whole project :)