Do Front-end Developers need to code custom modules, too?

Hi,

We're a Drupal shop, and we see some pretty clear distinctions beyond what is mentioned here. First of all, @greta_drupal, we do value site builders -- it's just that they're hard to find because that's a pretty Drupal-specific skill.

Here's how we break down the skill sets into roles:

• Site Builder/Architect: responsible for architecting the information on the site, deciding what goes in a content type vs a vocabulary vs a new entity type, etc. At entry level, this is building fields, views, permissions, etc.
• Front-end/themer: responsible for taking a design, picking a base theme, implementing the CSS/HTML/templates, considering mobile/responsive design, building sprites, etc.
• Back-end/module developer: Creates custom modules as necessary, creates integrations with other systems, handles data import, spends a lot of time in the debugger tracking down the source of bugs. Also more advanced Javascript/browser work, form API, etc.
• System Administrator/performance engineer: handles deployment issues, performance and scaling issues, profiling, configuration management.

We see a fair amount of overlap between these roles, but when I'm hiring, I'm looking to find somebody who can become a strong resource for the rest of the team in one of these areas. They do all seem to come with quite distinct personalities ;-)

We're a small enough team that we encourage learning the other roles, but each of these areas has a leader who defines our shop standards in that area.

Graphic Design is separate from front-end/theming, and typically our clients provide that.

Testing/QA could probably be another role -- but we're making that part of everybody's job description, to create test cases relevant to their areas (and then actually doing the testing is turning out to be a great way to train people new to Drupal in what can be done with it, where to find things, and generally the Drupal way...)

Each of these roles also has a growth/development path. We start out with people who have some basic skills in at least one area, but there's always a ton of things for each role to learn to really master that role.

For example:

• Site Builder: starts with content types, taxonomy, views, and planning URL structures. Mid-level - features, views arguments, ubercart/commerce, simple rules, context. Advanced: Panels, rules, workflow, Maestro, messaging/notifications, SOLR, etc.
• Themer: basic: HTML, CSS, grid-based designs. Midlevel: Sprites, responsive design, video/media. Advanced: UI/interaction design, animations, Facebook apps, custom widgets, mobile
• Back-end: basic: Form API, Database API, Schema API, ability to debug, custom filters. Midlevel: Bulk node operations, data synchronization, Rules components, views handlers, Services, drush scripting. Advanced: node.js, dojo toolkit widgets/AMD, query altering, core development
• System admin: basic: Linux shell, server management, drush, git, mysql/mariadb, apache/postfix, ec2/Cloud Servers, DNS, firewall rules, DOS mitigation, backup management. Midlevel: database indexing, slow queries (explain select), multi-server deployments, database replication, load balancing, disaster recovery planning, PCI compliance, monitoring setups. Advanced: diagnose hacked sites/servers, High availability setups, security planning, offline self-contained appliances, penetration testing, memcached/varnish, CDN setups, HIPAA documentation
  At least, that's how our current team is organized, and a partial list of the kinds of things each person does.

So yes, the main site building role in Drupal needs no PHP or programming knowledge whatsoever, and can get quite a lot done. Our back-end developers don't need CSS knowledge. Our front-end developers can get by with rudimentary PHP skills, as long as their CSS is strong. Finding a person who can do everything above well is probably not going to happen ;-)

I've looked at - or received in my email - a number of job postings and I too "abort" once I see custom module development. I don't write modules. I have taken courses in PHP and had to write my own CMS for my final project, but it is not what I love to do. I don't love writing software - I love designing and setting up sites.

I can create a design, take a design from Photoshop/Illustrator/PDF/etc. and make a theme, completely set up a site including views/panels/og/etc., bring in all the content, etc. Even though I do have to do some php work in the themes, I don't see that as the same as creating custom modules. Often times you can have a base theme that you create and then everything from then on is just html/css.

Basically I do everything but create custom modules. But as soon as I see someone wants that, I don't apply for their work.

It can take a considerable amount of time keeping up with everything you need to know to write custom modules. Instead I spend that time keeping up with new features I can add to the site, new ways of creating themes, changes in html/css, etc. I'd much rather be really good at all of the other things that create the bulk of a site.

**Edited Note: Looking at this again, I suppose this doesn't really directly answer the question, but if you can provide value in any one of these areas, that makes you a pretty strong team member for any shop that is into module development in my opinion. Front-end and back-end work are both critical to a high-quality module.

Truly competent module development requires a mixture of skills - these may be spread out over a few team members, however. Here are what I see as the critical components of successful module development:

• Architectural Integrity

All of the work you'll ever do on a module, today and in the future, depends heavily where information lives and how it relates to other data structures. Before walking into any module development, it is critical to have a clear understanding of how your system gets the job done.

Use Case documentation is an absolute must-have, and Entity Relationship Diagrams are critical for any module tasked with data processing / refinement. Failure to take this step often leads to a lot of shrugging and guesswork, which feels fine moving forward, but is murder on your budget and on your energy levels as you try to pull everything together.

With a little bit of planning, you'll find yourself going down a highway with a clear map allowing you to say 'I am here', as opposed to wandering a forest and looking for familiar landmarks to help you get your bearings. Guess which method gets you to your destination faster...

• Theme Layer Integration

You don't need to be a styling wizard to rock the theme layer. In fact, if you're doing it right, you should be able to take advantage of the tools provided by the theme layer which make it incredibly easy to provide output to the browser in a way that agrees with the site's core theme - no CSS, and often no HTML - is required to do this on basic displays. That being said, if your module provides any sort of HTML output whatsoever, it is very imporant that you understand how to utilize the incredible and extensible toolkit that is provided by the theme layer.

It takes a little bit of work to get used to the theme system - at first glance it seems convoulded and way too complicated. However, as you do more and more projects you will likely find yourself wishing you had more control over how output to the browser gets processed, and you will find that the theme layer has your back (especially in D7). In the meantime, you can get by with just hook_theme(), the theme() function and some custom functions that are in charge of producing output. Most importantly, use of the theme layer allows for separation of the site's logic and presentation, which is a must have for any quality-built software system.

If you're looking for advanced UIs, there is much more work there - not least of which has to do with your sever and your browser talking to eachother in a very effective way. Theme has tools to provide for the addition of javascript, so if you know how to make AJAX work already the tools provided by the theme layer can bridge the gap for you quite well.

• Proper use of Drupal hooks and APIs

This is debatably the most technically demanding aspect of module development. There are probably 30-or-so essential functions that you should never leave home without. With a clear understanding of the Views, Schema, Forms, and Entity (or node in 6) APIs, you can accomplish 90% of anything you might be tasked with as a Drupal module developer.

The hook system, while it is intimidating because of its sheer size, is blissfully easy to comprehend as soon as you wrap your mind around it. Part of what makes drupal so extensible and great is the fact that interacting with it from the code perspective is simply dropping in code that gets called at an expected time with some expected inputs.

If you can master the APIs, and you can master hooks - you're going to be pretty hard to stop. And you might be suprised at how much work it doesn't take to get you there.

• Integration with Drupal and the tools it provides

Finally, you're going to be much better off if you can identify the pre-existing tools which will get the hard work done for you. As a grand example if you're trying to build an eCommerce suite that allows you to purchase memberships, you're not going to want to build a custom eCommerce system that will allow you to do this. Instead, you're going to be much better off downloading Drupal Commerce and then writing a sub-module which allows for your custom handling.

The reasons for utilizing contrib modules are two-fold: 1) It is much, much faster to utilize tools already developed and at the ready 2) These ready-made modules have usually been extensively tested and, in all reality, will work much better than your version of the same module - at least until your solution has been through hundreds hours of testing and development.

Naturally, not every pre-made solution fits the way you need it to. Knowing when to go with off-the-shelf modules, and when to go custom, is a big part of being an effective module developer.

If you have all of these pieces in place, there is a good chance that you (or you and your team) have a great shot at making something worth while. While custom modules are not going to be the fastest or easiest solution for everything, module development gives you the control to do practically anything.

@katy5289 If you are looking for contract work, you can complement your skills with other freelancers case-by-case or form an LLC if you find someone with a good working relationship. You can work as a team or individually with separate business licenses. I know a few freelancers who operate that way.

I, too, walk away when I encounter job listings where "module developers" are being sought. Many of those ads are from firms that do want module developers. But I've had many clients (nonprofit orgs) who start out thinking they need full-on module developers to build their sites because--as many have pointed out--they're landing on buzz words to ensure they get what they think they need, because they don't yet understand what they need.

I've been freelance consulting in Drupal for two-and-a-half years, and I've had some success doing the following two things.

1. Collaborators: I find others with whom to collaborate who like to do/excel at the things I don't like to do (see below). I don't like to work alone, so this is ideal for me.

2. Focusing on finding the best matches between my skills and clients/projects: I tend to work with small to medium-sized nonprofit orgs on budgets with fairly straightforward needs. For most of these orgs, custom module development or very advanced Drupal tweakery is not only too expensive, it's can be very unwise. Most of these orgs simply need a modern CMS, but their needs are just a bit too complex for WordPress. What they need is clean, close-to-core, well-vetted-module Drupal implementation. This means they need an intelligent human person to help them navigate best practices of Drupal/CMS/open-source/nonprofit website building (communicating with an org to come up with a flexible, sustainable Drupal implementation plan to serve their needs is a skill in itself). If a potential client wants something too complex for my skills, I bring on another person to do that part, or I refer them to a larger shop. If an org is just getting to know Drupal, I will often give away a free half-hour or so to help educate them about Drupal, and learn about them myself so I can make a good referral if I or someone on my immediate team is not the best fit.

@Katrina my skill set sounds a bit similar to yours, though maybe a little heavier in code-comfort. I have a background in writing, but I spent over 10 years doing a combination of HTML/CSS CMS template coding and grant writing in non-profit orgs (as staff). I ended up with a lot of front-end code and site building skills: HTML, CSS, implementing jQuery and Javascript, and heavy use of Views, Panels, Context, whatever else. Over the years, I did teach myself how to implement PHP in templates/theme files when needed. (I've been working in Drupal for 6 years, and was in other open source CMSs before that.) I also have a lot of understanding about how nonprofits work, what their web needs are, etc. As I said, I definitely use that in my work.

What I don't enjoy and don't do are: designing/producing Photoshop comps, IA and data modeling, server administration, back-end data migration, and module patching and custom development. So it's people with those skills that I look to collaborate with.

Of course job listings ask for the moon. How many of the developer rockstars actually have CS degrees? Like most careers these days, chutzpah and the ability to learn will take you far.

The reality of Drupal is that it helps to know the APIs, and to know how to code even just a little. In my experience to stay on top of tech you constantly have to learn new things anyway. I wouldn't consider myself a module developer. I would consider myself a hardcore themer.

Don't shy away from code because it's unfamiliar it's easier than you think, and can actually be addictive. Sams "Teach Yourself PHP in 10 MIns" is also a good start to understanding PHP in general and it's a simple read. The Definitive Guide to Drupal 7, and Pro Drupal 7 are also helpful in the the theming/coding arenas.

If you can do a little bit of Drupal development you shouldn't have too much trouble finding a job.

I see this too, back-front end. I've been working exclusively with Drupal for 3-4 years as a site builder. I am about a 50/50 split. Even with this skill set, I can't get enough(any) work unless I write full site proposals.

@Megan - I always liked design also but it is so speculative from the client's eye. Nothing more fun than slicing previously well executed design elements into a theme.

I'm not sure what the community is saying when they claim there is not enough talent. Seems flooded with folks who are all rock stars and ninjas as most of the job reqs. want. Most recently I'm seeing the reqs. for LAMP admins along with the Drupal skills.

What is reality in this Drupal marketplace? For newcomers, I recommend concentrating on good php chops. No shortage of work there.

That's good to know, Gene. Thanks for posting that. I'm looking for telecommuting work.

Thank you to everyone who responded and left comments. I've really enjoyed reading them and learning about the wonderful talent we have in Drupal Front-end Developers and Themers.

I have met a couple Developers whose job description is Site Builder, but I don't recall seeing any job ads for that position. Perhaps Drupal Developer includes Site Builder? I like the title Site Architect better :-)

We had so much response, this discussion made "Top Content of the Week" on Drupal.org. Awesome!

Katy :-)
www.seascapewebdesign.com
Drupal Front-end Developer/Themer and Site Architect
Available for Hire