Mike Schroder Interview

Interviews

Meet Mike Schroder (@GetSource), WordPress Core contributor, happy DreamHost employee, coffee geek, and sailing enthusiast. Learn about how Mike got involved in WordPress, why he contributes, and how you can get involved. Yes, you. [Photo credit: Sheri Bigelow, a.k.a @designsimply.]

Tell us the story of how you got into working with WordPress. What itch did it scratch for you and what itch does it scratch for you today?

I started working with WordPress, like many, due to a desire to have a site and blog that were my own — something apart from any external services that might or might not be around in the years to come. Today, it still powers my personal blog and site. Contributing to the WordPress project and supporting WordPress helps both everyone at DreamHost, where I work, and the global community to scratch their itches. This makes me quite happy.

You got a shout out during Matt Mullenweg’s annual State of the Word address 2013, for being a recent WordPress rockstar. Tell us about your contributions to WordPress.

It was amazing and humbling to be mentioned next to such fabulous developers and designers. In 3.6, I worked with Andrew Ozz and Gabriel Coen on improvements to the post locking UI, local storage autosave, and login expiration notices. It’s always exciting to have a part in software that gets used by millions of people around the world. A bit frightening too, since the smallest change can have ramifications that are difficult to detect beforehand.

I suspect that much of the reason behind the mention was for WordPress 3.5, though, where I was listed as a Recent Rockstar. In 3.5, I worked primarily with Marko Heijnen to co-design and code WP_Image_Editor, which is an abstraction of the WordPress imaging API. It was the culmination of a ticket from Matt, #6821, created in 2008, that requested support for ImageMagick be added to Core. As part of the project, ImageMagick support (via the PHP Module Imagick) also entered Core in 3.5, using the WP_Image_Editor API. It was a pleasure to work with Marko, Japh (Thomson), and other contributors. It really was a team effort.

Tell us how you became involved as a WordPress Core contributor. What motivated you to get involved? What have you learned from working with the Core team? What is the legacy you hope to leave?

I’ve always been a fan of open source, and strive to leave more code in the open than behind closed doors. While there were a couple projects that I’d previously made open source, I hadn’t contributed to WordPress Core until starting work with DreamHost as a developer. Just over two years ago, I was brought on as a WordPress specialist to help DreamHost connect to the community and give back. Over time, I slowly learned the contribution process, got to know the Core Team and contributors better, and gradually worked on larger projects for releases. What the Docs group is doing to make it easier to learn to contribute via the Core Contributor Handbook is really cool, and makes it easier to take the first steps in getting involved. It’s not any less exciting to have code get shipped with WordPress than it was the first time. Not sure if that will ever get old, and I love helping others discover that feeling as well.

I’ve learned a ton from working with everyone involved in Core — much more than I can convey in a few sentences.

One important thing, though, is that any individual’s code can be elevated through feedback from the community. This helps WordPress be better for everyone as a whole. Code review in WordPress Core development is huge, and comments regarding potential improvements of your code should not be taken personally. This is something that is still hard to remember at times, but review has helped to improve my PHP and JavaScript skills significantly. I doubt I’ll ever stop learning from the Core Team and contributors.

In terms of legacy — this is something I’d not thought about much previously. On the personal side, I’d like to be someone who is helpful to those who ask and guides newcomers to feel welcome and contribute more easily. On the technical side, I hope to be someone who builds solid APIs and UX that stand the test of time, and are properly extensible for both plugin developers and Core itself.

You’ve contributed to three plugins: Varnish HTTP Purge, Gmagick, and Featured Image Column. What was the most important thing you learned in working on these plugins (good and/or bad)? What advice can you offer to emerging plugin authors?

I’ve actually done far less public plugin work than I’d like, but the biggest thing so far is “release early, release often.” There are plugins I’ve put on the back-burner because they weren’t “good enough” to be released yet. It turns out that if you release earlier, you benefit from the testing, feedback, and patches of others, which aids in making the plugin better for everyone. Also, it actually gets released.

While the WordPress Core Contributor Handbook is being made with loving care, what advice can you offer to someone who is thinking about getting involved in Core WordPress but isn’t sure of how to get started without stepping on others’ toes?

The docs team is doing a great job in filling out the Core Contributor Handbook.

In the general sense, don’t worry about stepping on others’ toes unless it’s obvious that the trac ticket you’re looking at is a major feature for a release. It’s incredibly common for tickets to be solved through a mix of patches from different contributors.

If in doubt, join #wordpress-dev in Freenode, and ask someone mentioned in the ticket — or the room in general. If you don’t get a reply right away, or don’t see the user online — don’t fret! Many of those who work on WordPress core live in different time zones. This means that after the weekly WordPress developer chats is a great time to ask any questions you have regarding a bug, since most contributors are online then. I highly recommend attending the dev chats regularly if you’re interested in contributing code to Core or if your business depends on WordPress. Even if you don’t have anything to add to the discussion, you can learn exactly what’s going on with the project first-hand.

What’s the most important thing to keep in mind when accepting feedback about your code from the community. Being so vulnerable can be a bit frightening, no?

Yes, it certainly is intimidating! The most important thing to remember is that everyone on the project is looking to make WordPress the best software it can be. Criticism of your code is not meant to be personal. Sometimes I have a hard time keeping this in mind with code I’ve spent a lot of time on. However, think of it this way: when you post a patch for review, it gets critiqued by some of the best developers in the world. It’s certainly fine to disagree with them and discuss the suggested changes, but it’s also a chance to get priceless feedback and improve your craft.