6 ms·

If you're using Drupal the way the author describes here - building in the interface rather than writing code - then yes, you're pretty much doomed. You're prod

If you're using Drupal the way the author describes here - building in the interface rather than writing code - then yes, you're pretty much doomed. You're producing a very fragile thing that is very hard to maintain and adjust later on, and heaven help you if you actually want to do something in a different way than the modules you're working with allow out of the box. Drupal development is very divided between (a) the small number of people who can treat it as a framework and write solid custom code while still making good reuse of core and contributed modules to speed development versus (b) the much larger number of people who treat it as a sophisticated CMS with plugins, and typically use Views and template overrides to produce a fragile solution. On the money side of things - yes, if you're in group (a), then you can charge a bunch of money. Drupal development is very lucrative. If you're in group (b), then no. That's just an average wage.

jtreminio 14y ago
What would you recommend an experienced developer coming into Drupal do to land in group A?
- rybosome 14y ago
  I had a lot of difficulty finding good learning resources for developers. Most are aimed at non-programmers. I had quite a few questions answered on http://drupal.stackexchange.com/ http://drupal.stackexchange.com/, which is a good starting point.
- exratione 14y ago
  - Write a module with at least some UI to scratch an itch. - Then figure out how to contribute it to the community as a release on drupal.org. Both parts of that process are equally valuable.
- knieveltech 14y ago
  Group A is guarded by a learning curve like the Swiss Alps. The only way to get past that is to get as much exposure as possible. There are already some excellent suggestions here so I won't rehash those, some other things you might consider: Idle in #drupal and #drupal-support. Whenever an interesting question gets asked, go figure it out if you don't know the answer already. Try tackling a few issues in the novice queues for D8. Not only will you get the kind of low-level exposure to how core really works that so many "Drupal developers" lack, you'll also get some nice bragging rights when your name's listed with the rest of the contributors. The next time you encounter a limitation with a module you're using, in addition to hook_$N_alter()'ing the fuck out of it, try writing a patch that cleanly extends the module to do what you want. Open an issue in the module's issue queue and submit your patch. Code review can be tough to take but stick with your issue until your patch is either accepted or the module maintainer closes the issue (won't fix, whatever). Try landing a gig with Acquia or some other big Drupal shop. You'll get to work with (and learn from) some of the top talent in the community and you'll get the kind of exposure you can't get experimenting in your spare time. If you're serious about going pro with Drupal development drop me a line. I may be able to help and would be happy to introduce you to others in the community.
- mechanical_fish 14y ago
  Try learning Drupal from a person first. A meetup or a Drupal camp are very good. A video is the fallback: Try NodeOne: http://nodeone.se/sv/learning-library http://nodeone.se/sv/learning-library or drupalize.me: http://drupalize.me http://drupalize.me
patrickocoffeyo 14y ago
Yes, and amen. All people who are afraid to write code need to stop using drupal.
- mcrittenden 14y ago
  There's a difference between beinf afraid to write code and avoiding reinventing the wheel. If there's a Drupal module that gives you what you need, why would you not use it?
  - jackbravo 14y ago
    it all depends. Example, if you want to assign a role to a new user when he signs up you can install http://drupal.org/project/autoassignrole http://drupal.org/project/autoassignrole module which does about 10 more things or just write one hook_user function. If you install a module for every piece of functionality soon you'll end up with a huge codebase and the hell the author is describing.
    - Pwnguinz 14y ago
      You are responding to the author ;). That said, I wholeheartedly agree. Did Drupal dev for 2 years, and my biggest takeaway was: Don't go around installing custom modules for one dinky feature. Wrap it up in your own custom module. Less dependency hell to deal with, and not only that, you'll have a much easier time debugging code you wrote yourself.
  - ams6110 14y ago
    A lot of the smaller drupal modules are unmaintained, buggy, or just plain don't work. Drupal advocates like to brag about the thousands of developers and modules in the ecosystem, but the truth is only the core modules and the most widely used contributed modules are production-worthy.
    - mtts 14y ago
      That, and even core-ish modules are maintained in a manner that's just plain unprofessional (I'm looking at you, Ubercart / Drupal Commerce): "Hey, there's a new version of Drupal Core! Let's drop development of (and support for) the current version of Ubercart that people are actually using and start writing a completely new cart system from scratch!"
mcrittenden 14y ago
This comment confuses me. If you're going to use Drupal as a framework and ignore the rest, then why not just use Django or Rails, both of which are cleaner and more sophisticated frameworks? I don't think it's fair to look down on people who use Drupal as it's meant to be used.
- jack-r-abbit 14y ago
  I don't think it is fair to throw all Drupal developers into a bucket that has them rarely writing code and mostly just clicking around. We have a Drupal Role for people that only do what you describe. We call it Site Admin. They get access to all the clicky parts but don't do any actual programming. I'm never bored with Drupal. Frustrated yes... but never bored.
- vaporstun 14y ago
  Drupal developer with 4+ years of working with it under my belt. The nitty gritty is that we use it in an environment where we basically have 2 teams. One that builds custom code/modules that can be installed and enabled in Drupal to add additional functionality and another that actually deploys sites. The team that deploys sites is savvy, but are not hardcore developers. The thing I've come to over all these years is that Drupal's pluggability still makes it the most powerful tool for what most people use it for -- deploying websites. I have often surveyed the landscape and thought, "why not just build this in another tool like Rails or Django" and I always come back to it in much the same way the author of this article does -- while those are much more beautiful development frameworks, they just don't have the mojo that Drupal does. This is likely best illustrated by example. This may or may not be based on a true story ;) Let's say I develop a custom application to interact with my company's backend database products which, let's say, are for events management. Now I pass that custom application off to the site builders who will actually customize that application for each of our hundreds of clients. (1) The client wants a Google map of all their events (2) The client wants the Events displayed on a calendar (3) The client wants Events to filter by Event type (4) The client wants a tag cloud or something else totally unrelated to the Events system Built in Rails (Total additional developer time to add these features: 400+ hours) (1) Damn, back to the drawing board, we need 100 more hours of dev time to develop a custom component to convert the locations into actual location data (lat/long) and display it on a map. We need to interact with the Google Maps API and write the code that will communicate with them via an API key and handle everything. (2) Damn, back to the drawing board, we need 250 more hours of dev time to build a calendar and ensure we get the layout correct, handle a bunch of special cases (what if there are too many events to display on a single day, some months have 4 rows of weeks, some have 5, etc.) (3) Developer has to add a form element to take that event type and modify a query to enact that filtering and load the results on a new page. Not a ton of dev time, but dev time nonetheless. (4) Cross fingers that there is a Ruby Gem for this. Otherwise damn, custom development. Built in Drupal (Total additional developer time to add these features: 0 hours) (1) We never heard back from the site builders because they installed the Drupal modules Views, GMap, Location, and were able to create the map themselves from our custom Event data and clicking on the right buttons (2) Again, the developers never heard back from the site builders because they installed the Drupal modules Views, Calendar and were able to show those events on a calendar. (3) No developer time because the site builder went into the Views settings and added an Exposed Filter (4) Site builders install the cloud tag module or the random feature X module, custom developer time rarely needed. Now let's scale it up, instead of 1 client you have 500 and each want slightly different things. One wants to filter by Event type, one wants to filter reverse chronologically by date. One wants a calendar with a month view, one wants a week view. One has a ton of events and wants a day view. With Drupal, these are all just settings on existing, already built modules. With Rails/Django/Node.js/etc. these all require more dev time. Now of course things could be designed intelligently and parameterized to limit some of the DRY, but there is still dev time required to implement all these different permutations or up front complicated system design to create an architecture that can be configured as richly as a Drupal module developed over years by a community. I work in Drupal professionally, but play in Rails, Django, Node.js, even Meteor every chance I get because they're so fun and beautiful but at the end of the day I still think Drupal is the right tool for our job in spite of its long list of flaws including its base language, the always horrifying PHP. But it freaking works. tl;dr This article rang more true than I could have imagined it would. Thanks mcrittenden!

jtreminio 14y ago

What would you recommend an experienced developer coming into Drupal do to land in group A?

rybosome 14y ago
I had a lot of difficulty finding good learning resources for developers. Most are aimed at non-programmers. I had quite a few questions answered on http://drupal.stackexchange.com/ http://drupal.stackexchange.com/, which is a good starting point.
exratione 14y ago
- Write a module with at least some UI to scratch an itch. - Then figure out how to contribute it to the community as a release on drupal.org. Both parts of that process are equally valuable.
knieveltech 14y ago
Group A is guarded by a learning curve like the Swiss Alps. The only way to get past that is to get as much exposure as possible. There are already some excellent suggestions here so I won't rehash those, some other things you might consider: Idle in #drupal and #drupal-support. Whenever an interesting question gets asked, go figure it out if you don't know the answer already. Try tackling a few issues in the novice queues for D8. Not only will you get the kind of low-level exposure to how core really works that so many "Drupal developers" lack, you'll also get some nice bragging rights when your name's listed with the rest of the contributors. The next time you encounter a limitation with a module you're using, in addition to hook_$N_alter()'ing the fuck out of it, try writing a patch that cleanly extends the module to do what you want. Open an issue in the module's issue queue and submit your patch. Code review can be tough to take but stick with your issue until your patch is either accepted or the module maintainer closes the issue (won't fix, whatever). Try landing a gig with Acquia or some other big Drupal shop. You'll get to work with (and learn from) some of the top talent in the community and you'll get the kind of exposure you can't get experimenting in your spare time. If you're serious about going pro with Drupal development drop me a line. I may be able to help and would be happy to introduce you to others in the community.
mechanical_fish 14y ago
Try learning Drupal from a person first. A meetup or a Drupal camp are very good. A video is the fallback: Try NodeOne: http://nodeone.se/sv/learning-library http://nodeone.se/sv/learning-library or drupalize.me: http://drupalize.me http://drupalize.me

patrickocoffeyo 14y ago

Yes, and amen. All people who are afraid to write code need to stop using drupal.

mcrittenden 14y ago
There's a difference between beinf afraid to write code and avoiding reinventing the wheel. If there's a Drupal module that gives you what you need, why would you not use it?
- jackbravo 14y ago
  it all depends. Example, if you want to assign a role to a new user when he signs up you can install http://drupal.org/project/autoassignrole http://drupal.org/project/autoassignrole module which does about 10 more things or just write one hook_user function. If you install a module for every piece of functionality soon you'll end up with a huge codebase and the hell the author is describing.
  - Pwnguinz 14y ago
    You are responding to the author ;). That said, I wholeheartedly agree. Did Drupal dev for 2 years, and my biggest takeaway was: Don't go around installing custom modules for one dinky feature. Wrap it up in your own custom module. Less dependency hell to deal with, and not only that, you'll have a much easier time debugging code you wrote yourself.
- ams6110 14y ago
  A lot of the smaller drupal modules are unmaintained, buggy, or just plain don't work. Drupal advocates like to brag about the thousands of developers and modules in the ecosystem, but the truth is only the core modules and the most widely used contributed modules are production-worthy.
  - mtts 14y ago
    That, and even core-ish modules are maintained in a manner that's just plain unprofessional (I'm looking at you, Ubercart / Drupal Commerce): "Hey, there's a new version of Drupal Core! Let's drop development of (and support for) the current version of Ubercart that people are actually using and start writing a completely new cart system from scratch!"

mcrittenden 14y ago

This comment confuses me. If you're going to use Drupal as a framework and ignore the rest, then why not just use Django or Rails, both of which are cleaner and more sophisticated frameworks? I don't think it's fair to look down on people who use Drupal as it's meant to be used.

jack-r-abbit 14y ago
I don't think it is fair to throw all Drupal developers into a bucket that has them rarely writing code and mostly just clicking around. We have a Drupal Role for people that only do what you describe. We call it Site Admin. They get access to all the clicky parts but don't do any actual programming. I'm never bored with Drupal. Frustrated yes... but never bored.
vaporstun 14y ago
Drupal developer with 4+ years of working with it under my belt. The nitty gritty is that we use it in an environment where we basically have 2 teams. One that builds custom code/modules that can be installed and enabled in Drupal to add additional functionality and another that actually deploys sites. The team that deploys sites is savvy, but are not hardcore developers. The thing I've come to over all these years is that Drupal's pluggability still makes it the most powerful tool for what most people use it for -- deploying websites. I have often surveyed the landscape and thought, "why not just build this in another tool like Rails or Django" and I always come back to it in much the same way the author of this article does -- while those are much more beautiful development frameworks, they just don't have the mojo that Drupal does. This is likely best illustrated by example. This may or may not be based on a true story ;) Let's say I develop a custom application to interact with my company's backend database products which, let's say, are for events management. Now I pass that custom application off to the site builders who will actually customize that application for each of our hundreds of clients. (1) The client wants a Google map of all their events (2) The client wants the Events displayed on a calendar (3) The client wants Events to filter by Event type (4) The client wants a tag cloud or something else totally unrelated to the Events system Built in Rails (Total additional developer time to add these features: 400+ hours) (1) Damn, back to the drawing board, we need 100 more hours of dev time to develop a custom component to convert the locations into actual location data (lat/long) and display it on a map. We need to interact with the Google Maps API and write the code that will communicate with them via an API key and handle everything. (2) Damn, back to the drawing board, we need 250 more hours of dev time to build a calendar and ensure we get the layout correct, handle a bunch of special cases (what if there are too many events to display on a single day, some months have 4 rows of weeks, some have 5, etc.) (3) Developer has to add a form element to take that event type and modify a query to enact that filtering and load the results on a new page. Not a ton of dev time, but dev time nonetheless. (4) Cross fingers that there is a Ruby Gem for this. Otherwise damn, custom development. Built in Drupal (Total additional developer time to add these features: 0 hours) (1) We never heard back from the site builders because they installed the Drupal modules Views, GMap, Location, and were able to create the map themselves from our custom Event data and clicking on the right buttons (2) Again, the developers never heard back from the site builders because they installed the Drupal modules Views, Calendar and were able to show those events on a calendar. (3) No developer time because the site builder went into the Views settings and added an Exposed Filter (4) Site builders install the cloud tag module or the random feature X module, custom developer time rarely needed. Now let's scale it up, instead of 1 client you have 500 and each want slightly different things. One wants to filter by Event type, one wants to filter reverse chronologically by date. One wants a calendar with a month view, one wants a week view. One has a ton of events and wants a day view. With Drupal, these are all just settings on existing, already built modules. With Rails/Django/Node.js/etc. these all require more dev time. Now of course things could be designed intelligently and parameterized to limit some of the DRY, but there is still dev time required to implement all these different permutations or up front complicated system design to create an architecture that can be configured as richly as a Drupal module developed over years by a community. I work in Drupal professionally, but play in Rails, Django, Node.js, even Meteor every chance I get because they're so fun and beautiful but at the end of the day I still think Drupal is the right tool for our job in spite of its long list of flaws including its base language, the always horrifying PHP. But it freaking works. tl;dr This article rang more true than I could have imagined it would. Thanks mcrittenden!