Meet Greg Anderson, an open source contributor at Pantheon and co-maintainer of Drush. If you’ve used Drush before, you’ve probably saved a bunch of time on repetitive tasks. If you haven’t used it yet, what are you waiting for?

Greg Anderson is all about boosting productivity and improving development workflows. He shared some of his insights in this interview. We also found out how he got involved with Drupal and got a preview of his session at DrupalCon NOLA on command line tools for Drupal 8 modules.

How did you get involved with the Drupal community?

I started using Drupal because I needed an open source content management system (CMS) to use in several community projects. One of the projects I was involved with was just getting started and had narrowed its CMS selection down to either Drupal or Joomla. At the time I was using a different framework, but I had considered Drupal in the past and knew that I liked it a lot better than Joomla. I convinced them to go with the new Drupal 6 release and converted all of my other projects for consistency. I started working with Drush because I wanted a unified mechanism to work with local and remote sites. My first major contribution to Drush was site aliases and sql-sync in Drush 3.

What’s it like being the co-maintainer of Drush?

It seems like everyone uses Drush now, but not very many people recognize me by sight. I am much more likely to be recognized as a member of the planning commission in my town than as an open source contributor anywhere else. Even at a DrupalCon or camp, if I introduce myself to someone I do not know, they will often suspect something and start guessing, “Are you Greggles? Are you @heyrocker?” This is more common than you might think. Working on Drush is more something I do than something I am, though. I find it extremely rewarding to make improvements to tools that shave time off of repetitive tasks and make things easier to do. It feels super good to see someone blog or tweet that the job they just did was a lot easier because of something I wrote.

Can you share any advice or recommend any books on improving development workflow?

I thought that Drush for Developers by Juampy Novillo Requena came out particularly well (I was the technical reviewer for this book). However, setting up and maintaining your own dev/test/live workflow is really expensive in terms of the time it takes to get it working. There are a number of good providers who have free-to-get-started, pay-to-launch professionally managed solutions that will save you a lot more than they cost, and this will compound over the long haul. This is really the smartest way to approach your development workflow.

What are a few things you’re looking forward to at DrupalCon NOLA?

I usually end up missing most of the sessions at DrupalCon because I find it so valuable to work with other contributors face-to-face in the sprints. I always enjoy seeing many of the same familiar faces from all over the place at each event and meeting new people I may or may not have interacted with previously online.

Tell us about your DrupalCon talk, Writing command line tools for Drupal 8 modules. Why should someone attend, what are the major takeaways?

A command-line interface to the functionality provided in a module can be a huge benefit and productivity boost. The Features module in particular demonstrated this with its Drush commands to update, revert, and create features, which have been widely used throughout the Drupal community. However, no one wants to have to become an expert in writing command line tools just to add another interface to their module. Drush commands and Symfony Console commands are not difficult to write, but over time we can refine and improve how this is done in ways that decrease the amount of code that needs to be written, keep components decoupled, and provide more out-of-the-box functionality while lowering the barrier to entry for new contributors. In the open source community, there are a lot of different opinions about how things should be done, so the attendees of this session should expect a lively discussion on when an whether an API should be extended and improved, and when it is better to favor the more explicit option of using the existing interfaces directly.