Scott Taylor Interview

Interviews

Scott Taylor @wonderboymusic is full-time developer at The New York Times who writes code to pay the bills and to fuel his love of music. A classically trained musician, Scott plays lead guitar for Goodbye Picasso. Find out how he got involved in contributing to WordPress Core and learn about some great new features bands and musicians can take advantage of to strut their stuff with WordPress 3.6.

Tell us the story about how you got into working with WordPress. What itch did it scratch and why do you continue to use it today?

I started working with WordPress as a blogger in 2007 and as a developer in 2009. I got offered some freelance work, and they said “use WordPress.” I had been using various PHP MVC frameworks for a while (especially CakePHP) and maintaining a bunch of custom CMS code I wrote for use across multiple projects. (Any developer with any sense will immediately cringe at that statement.) I had mixed feelings about WP development using 2.8 and 2.9, but 3.0 really sold me on its extensibility and ease of use. BuddyPress and Shopp blew my mind soon after. My mind was racing with all of the great things I knew I could build with them, and it made me realize I could take on any project and probably use an off-the-shelf solution to solve big problems.

When we were in discussions to do a platform shift at eMusic, I knew it was a now-or-never situation I was in to push for WordPress to be used as our CMS. The migration was really a two-year process, and I consistently felt like we made the right decision as we moved business-critical pieces from our legacy platform to our services-oriented platform fronted by WP. WP drastically increased our productivity and made the site easier to manage for everyone involved.

I recently left eMusic after five years for The New York Times, where I work on the Blogs team. The Times has over 100 developers, and three of us work on blogs. Blogs at the Times come and go, but there have been about 200 launched at one time or another. It’s cool to work on a product that has such global reach. WP gives writers at the Times more flexibility than some of the other internal tools here.

What are some of the unique challenges The New York Times faces with its blogs and how have you started to overcome them?

The main challenges are risk/change management: how do we confidently upgrade and move our code forward without disrupting a lucrative operation that is churning out lots of content daily using an existing workflow on a legacy codebase? Lots of planning goes into every move we make. The NYTimes has been using WordPress for a long time (since 2006). Along the way, the developers here came up with some homegrown solutions for problems — things that weren’t in WordPress yet, or things needed internally. When core moves forward with a similar feature, or an unrelated one that still might intersect with ours, we have to create a plan to migrate to core’s implementation or work around it.

You’re active in WordPress Core, squashin’ bugs, writin’ code, and takin’ names. Why do you choose to give so much back to the community? What have you, personally, gained from being involved?

I started contributing to Core in 2011. I found some bugs while writing some intense code at eMusic and didn’t want to hack Core. After coming up with some workarounds, I brought them up to Andrew Nacin at WordCamp San Francisco. My first contribution was actually committed by him while we were at the after-party at the old Automattic space on the Pier. Nacin and Koop gave me confidence that my bug reports would get looked at if I started reporting them, so I filed a few Trac tickets here and there. I think I had one commit each in 3.2 and 3.3.

Starting with 3.5, I decide to subscribe to Trac and see how a dev cycle actually works. Getting the firehose of emails gave me a great window into the ebb and flow of tickets and how the Core team deals with them. Rather than focusing on my pet tickets, I started looking for existing tickets that I could help patch. I felt like I had a deep understanding of WP internals and could contribute in a number of ways. I also had the real-world experience of things like: a DBA standing over me at my job and saying “X query is slow” — the query was being generated by WP core. I didn’t have the luxury of saying “not my fault” — I had to get in there and find a way to alter it. So, in a number of cases, I would bring those learnings back into WordPress Core.

Having your code committed is exciting, but my main focus is getting as much stuff fixed as is possible. I regularly look for tags like “3.2-early” in Trac and try to make sure the good work of others past is not abandoned. I do this work for a lot of reasons, one being professional development, but I also want my framework of choice to be as good as possible. If there’s 3000+ open tickets, my goal is to get that number down to 1000.

How has your view of WordPress changed since you’ve become much more involved in Core?

WordPress, to me, is a code framework I can build on top of. The more I participate in Core dev, the more I learn. I guess I have changed my attitude from “WordPress should fix this,” to “How do I make a case for this feature?” or “What’s something I can work on that I know needs love?” I also absolutely believe now that WordPress is a meritocracy. I went from “What’s a custom taxonomy?” in 2009 to “Here’s the code I’m contributing to Core,” in 2011. If you put the work in, you can be involved as much as you want.

If a young developer asked you for advice on getting involved in the WordPress community, what would you say?

A few things:

1. Your code will be reviewed by people who know more about WordPress than you: listen to them and learn. It doesn’t matter what the code looks like in the end. Eventually, you’ll know what the lead devs are looking for in a patch and code accordingly. Eventually, if no one has any feedback for you, your patches could go in right away.
2. Pertains to the project as a whole: don’t wait for someone else to champion your causes. If you feel strongly that something should be in Core, or that your ticket is the most important thing that has ever happened…stay involved! I talk to a lot of people who will file a Trac ticket and then disappear. The Core team has so much going on, you need to speak up at dev chat and make your case. You might get shot down, but don’t be discouraged. There is a legacy of knowledge and process that you may not have been privy to. I have yet to see any amazing idea turned away completely. Sometimes it’s a matter of “Sure, but not now.”

You play lead guitar in a band called Goodbye Picasso. How does making music fuel your creativity?

Music is my entire life. Software engineering is the way I make a living and live in New York City. I majored in classical music (I used to play a mean trumpet) in college and only learned the web when my band needed a website. The band has been around in various forms since 2001 and has played over 600 shows. I enjoyed the web as soon as I started making my first site, mainly because I feel it is another form of expression and creativity. Adding support for Audio and Video in core was a goal of mine, because I want musicians and bands to have an easy way to post their content without needing various plugins or paid services. I was getting scared that everyone would just use Tumblr. In 3.6, WordPress makes it really easy.

What is it about 3.6 that “makes it really easy” for musicians and bands to have an easy way to post their content without needing plugins/paid services?

For musicians: the problem of “How do I post my music to my blog?” no longer exists. Tumblr has an inline player for audio, inline player for video. WordPress has plugins, some of which cost money. Audio and Video are two of the core “post formats” WordPress supports, but, without “inline players,” I don’t see much “support.”

It’s unfortunate that the Post Formats UI didn’t make it into 3.6. I spent a bunch of time this year working on it, but that’s show business! However, the work I did for Audio and Video remains, and there’s a lot of automagic in there:

• When you insert audio or video from the Media Library now, your post will be populated with a shortcode that will automatically turn into an inline player on display. This also works if you leave an .mp3 URL on a line by itself in your post editor.
• On the Edit Attachment screen, you will now have an inline preview of your audio and video files.
• When uploading, the ID3 tags of the files are now read to pre-populate some of your attachment metadata fields: song title, album, artist, genre, etc.
• For advanced themers, if you add the post-thumbail feature and theme support to attachment:audio, and your MP3 contains an embedded image: the image will be saved in your media library and attached to the audio file.

The inline player is great, because it is customizable visually. The library we use for cross-browser support, MediaElement.js, uses the same HTML for the player in every browser, regardless of implementation, and lets you override its styles with CSS. MediaElement is great for compatibility — your files will play in every browser, and whenever supported, native HTML5 will be used.

I should probably write a tutorial about all of this, but some of it was already announced on Make/Core.

You’ve got 13 plugins to your credit. What’s motivated you to create and share your plugins? What advice can you offer users on how to get the best support from a plugin developer?

I built a few things here and there and thought: “if I need this, others will too.” Like I mentioned previously, I was excited about building things on top of BuddyPress, Shopp, Gravity Forms, etc. I liked being able to package my own code into plugins and one-click-install them when I started a new project. Full disclosure: I have been awful about maintaining them and fully supporting them in the forums, but for the most part, they have been well-received / others find them useful.