Looking Back on a Year at Automattic

Stephane Daury looks down as the sun sets from an overlook along a road to Waimea Canyon in Kauai, Hawaii. Photo  was taken during the 2013 Janitorial Team meetup.

Wow! It has been a year since I joined Automattic, a startup with employees scattered around the world working from wherever is most convenient (e.g. their home, a coffee shop, a co-working space, a beach with good wi-fi, etc…). After spending twelve years as a student, a graduate student, an instructor, and an employee at four different universities, the change was more dramatic than I thought it would be. But thanks to lots of support from my wife and colleagues, I was able to adapt and ended up having a bunch of fun, learning a ton, and accomplishing quite a bit.

Fourteen Things I Learned or Experienced

  1. Coming to work everyday is easy when you work on a service with millions of users, and on those rare days when it is harder to start cranking, Automattic’s mission to “democratize web publishing” and the creed are strong motivations.
  2. “Be the change you want to see.” A couple months ago during the annual Automattic Grand Meetup a colleague suggested that the most effective way to make an impact was to “be the change you want to see,” which was sound advice. Action is a more economical form of communication because the effort required feeds directly into creating something. Believing in your idea enough to build something also shows a level of commitment that is greater than just posting an idea.
  3. In the last year, I have made 574 commits to the WordPress.com source code repository, written 188 p2/o2 posts, commented 696 times, and made a couple small contributions to WordPress core. I hope that in the next year I am able to double my code contributions.
  4. “It is not what you say, it is what people hear.”  Understanding when the best time to hit publish, reading what you have written from perspectives other than your own, knowing how to communicate the right tone, and figuring out ways to nudge folks to read what you have written are all skills that need constant refinement.
  5. Written communication even via IRC or on Skype is more permanent than a face-to-face chat, which makes reflecting back on conversations easy, but it also makes throwing stream-of-conscience thoughts out more risky because everything is “on record.”
  6. I now use emoticons and appreciate their value, which I am sure would shock those that have known me for awhile. I also have a better handle on geek slang and memes. 🙂
  7. It is fantastic that Automattic trusts employees to make good decisions, to recognize mistakes, to correct them, and to learn from them. Transparency in combination with straightforward policies encourages responsible behavior without requiring the overhead and frustrations that come with layers of bureaucracy.
  8. Traveling to places like to San Francisco, HawaiiChicago, and Rome when I have to leave behind my wife and cute little girl is not as much fun as when I was single, although the time away is offset with working from home and able to watch Abigail when needed.
  9. Javascript is the language of the future (and present). Over the last year, I have written more javascript than PHP, and I now have a much better understanding of closures, promises, Mustache, RequireJS, functional programming techniques, HTML5 technologies, and Backbone.js.
  10. With both code and communication, reading carefully requires more concentration than doing the same when writing.
  11. Knowing when to take the time to create a reusable abstraction is hard, and creating good ones is even more difficult.
  12. Understanding when and how to empathize with your users makes it much easier to be confident that what you are doing will delight users.
  13. I don’t miss Microsoft Office.
  14. It is fun having a book written about your company.

The Big Picture

While I have learned a lot about programming over the last year, much of what I have learned has been about how to work in a distributed environment. It turns out that the process of creating software in a distributed company like Automattic has a lot of similarities with the process of creating and supporting software in large open source projects. In both cases, individual motivation and accountability in combination with transparency and free flowing communication help keep the train running smoothly. The geographic diversity of distributed companies also better reflects the nature and values of the open web than a company where everyone works out of a single office. It is no surprise that companies like Mozilla, Github, Canonical, RedHat, and MySQL are entirely distributed or have a substantial number of employees that work from home.

Looking Forward

In order to get a feel for how my peers felt about my first year, I decided to conduct my own informal “performance review” by sending out an email with a few questions to a group of colleagues. I received lots of great responses that made me both feel good and also challenged me to do even better. So as I look forward to 2014 and consider what I would like to accomplish, I came up with the following:

Dream big.
Do more.
Think hard.
Be nice.

Northeast PHP Conference Recap

Over the weekend, I attended the second Northeast PHP Conference at the Microsoft NERD center. Special thanks are due to Michael Burke and the other organizers who did a fantastic job organizing the conference.


  1. PHP is still powering a large percentage of the visitor facing portion of the web.
  2. Static arrays coupled with an opcode cache are a high performance way to store application configuration data, translations, and other static data required for an application. The benefit is that the data will be loaded pre-compiled from memory so no disk access or network connections will be needed. Etsy uses this technique for both translations and also feature switches.
  3. mPulse is a pretty awesome looking realtime performance monitoring and analysis tool. To collect the data, the service uses http://lognormal.github.io/boomerang/doc/.
  4. Wikipedia has a new front-end visual editor built using javascript/nodejs that makes heavy use of contenteditable. While there are lots of challenges to bring front-end editing to WordPress, I think that if done right, you can’t beat the user experience of being able to directly edit your content in the proper context.
  5. Building around HTTP (usually RESTful) is basically a no-brainer with the UX of native mobile apps winning right now and the future possibilities around the growing “internet of things.”
  6. It was nice to hear some positive mentions of WordPress sprinkled throughout including a compliment by Eli White on the newer code in the codebase in his opening keynote. Web apps are increasingly stitched together using various services and WordPress fits into this ecosystem well.
  7. Overall, there was not much said about the future of PHP the language. The only exciting thing that I heard was that HipHopVM will likely become part of the main PHP distribution at some point in the future.
  8. Don’t be data-driven, be data-informed. Data-driven takes the human out of the equation.
A tray of "Octocakes" thanks to GitHub. Image courtesy of @bluesmoon.
A tray of “Octocakes” thanks to GitHub. Image courtesy of @bluesmoon.


Looking to the Past, to Predict the Future- Eli White

Practical Responsive Web Design – Jonathan Klein (Etsy)

Scaling PHP to 40 Million Uniques – Jonathan Klein (Etsy)

The UX of URLS – Ryan Freebern

Pragmatic API Development – Andrew Curioso

Agile in the Workplace – Mike Stowe

Dependency Management in PHP: Better Late than Never

Don’t Be STUPID, Grasp SOLID – Anthony Ferrara

Up and Running with Bootstrap

jQuery Mobile: Sites that Feel Like Apps

Workshop: Clean Application Development

Magic Methods: Spilling the Secret – Matthew Barlocker

Git Essentials – Matthew Barlocker


You Can UX Too: Avoiding the Programmer’s User Interface – Eryn O’Neil

Workshop: Usability Testing for the Common Man – Heather O’Neill

Introduction to User Experience Design – Meghan Reilly

UI Patterns: A Practical Toolkit – Jim O’Neill

BackboneConf 2013 Recap

Last week, along with a few other developers from Automattic, I attended the BackboneConf 2013 at the Microsoft NERD center organized by the fine folks at Bocoup. The enjoyable two-day conference provided me with a better sense of the bigger javascript trends and gave me a bunch of practical tidbits.

The big theme was modules and how to best structure code so that dependencies are minimized, concerns are well separated, and unit testing is easier. With the inclusion of modules in ECMAScript 6 and the maturation of nodejs and AMD/UMD/CommonJS, modules are ready for prime time. Now I just need to figure out the best way to incorporate modules into WordPress, which already has a file-based javascript dependency management system.


  1. Underscore has lots of super elegant bits that I should take remember to use:
    // Set default key/value pairs if not included in the passed object (options)
    options = options || {};
    _.defaults(options, {
      showFollows: true,
      showLikes: true
    // take certain options and copy the properties to the destination object (in this case this)
    _.extend(this, _.pick(options, methodArray));
  2. Use an event bus and postMessage() to simplify messaging between parent document and iframe with embedded Backbone App.See http://benvinegar.github.io/backbone-at-disqus-talk/#/42
  3. Use requestanimationframe() and _.debounce() to avoid blocking the UI when doing expensive looping operations by chunking the work.
  4. Even when using Backbone, it can be very useful to store visual state in the DOM through using classes. It seems obvious in retrospect, but when in a Model-View-Whatever state-of-mind, it is easy to forget to take advantage of the DOM to store view state. This is especially useful for changing the visibility of certain child views in a collection view.
  5. Q seemed to be the preferred library for promises.
  6. Mocha, chai, and sinon seemed to be the preferred set of tools for writing javascript unit tests.
  7. Use promises to fetch data, templates, and any other dependencies in parallel when building up a page in a single-page app to improve the load time of pages.
  8. FastClick is a neat library for improving the responsiveness of click events on mobile if you don’t have any double-click events.
  9. IndexDB allows a client side app to store much more data than local storage


More About the Two Workflow Plugins that BU is Developing

I posted the following on BU’s Developers vs. Designers blog:

After almost 4 years building the BU CMS on WordPress MultiSite, the BU WebTeam, which consists of staff from IS&T and Interactive Design, has decided to release some of our plugins to the broader WordPress community. The first two plugins planned for release tackle some of the workflow limitations that content editors have been asking us to address for a few years.

The Problem

The BU CMS contains quite a few large websites. In most cases, the bulk of the content comprises of pages (the “page” post_type), so a significant percentage of the day-to-day content modifications are updates to published content. Unfortunately, WordPress does not provide any controls for restricting the editing of published content or limiting what content a particular user is allowed to publish, so if a user has the capability to edit one page, they can edit all pages. For sites that have more than 50 editors and over 1,000 pages, the primary site administrators worry that ill-advised changes will be made to prominent content by an editor with less experience or without the authority to make the change. In addition to cracking that nut, we wanted to provide a mechanism for staging an edit to a published page so that the change could be worked on directly (with its own revision history), reviewed, previewed, and scheduled for publication.

After reviewing some of the existing plugins that provide this sort of functionality, we decided to write two plugins to address these problems. Both plugins will be released under the GPL.

Design Goals

  • Blend naturally into the existing WordPress admin UI
  • Simple to use
  • Manage permissions with a full view of all post content
  • Perform well on sites with more than 2,000 pages
  • Support custom post types

BU Section Editing

The BU Section Editing plugin creates a new role: Section Editor and adds screens for managing groups of Section Editors. Each group is granted access to publish and edit published content for individual pages.

The group editor borrows UI elements from the post and menu editors.
Section editors are easily added/removed from a single screen. By using the group model, editors can be added/removed without having to worry about the permissions.
Controlling the group’s permissions is handled from a single view of all content.
Permissions are automatically applied to children for hierarchical post types.

BU Versions

The BU Versions plugin adds functionality for creating an alternate version of pages, posts, or any public custom post type. After cloning the post, editors are able to make and preview changes. When the changes are ready to be published, the user simply clicks “Replace Original” or schedules the replacement. Users that do not have the “publish_posts” capability are able to create and edit an alternate version, which makes an edit, review, then publish workflow possible even when modifying published posts.

Users choose whether to edit or clone from the list view.
Editing an alternate version is distinguished visually from the normal post editor.

We really want to get feedback from other folks using WordPress on large sites, so don’t hesitate to leave a comment on the original post.

WordCamp Boston 2012: WordPress Workflows Expanded

Boston University is hosting WordCamp Boston again this year, and I will be giving a talk. I am particularly excited to share some of the plugins that BU has been developing with the broader WordPress community.  Below is the description:

WordPress includes a well-defined workflow for running a blog with multiple contributors in various roles. It works great; But what if you are using WordPress to run a 1,000 page hierarchical site? Well… the workflows available are a bit limited without getting under the hood. For example, WordPress does not define fine-grained capabilities for controlling who can edit published content. As a result, users have to be granted full editing permissions, which increases the chance that a less-experienced user will make an ill-advised change. Drawing from our experience running large Multisite installations, Boston University has developed a couple of plugins to address some of the limitations. And for the first time, we are planning to release our plugins to the broader WordPress community under the GPL.

This talk will include an overview of the role/capability system presented from both a user and developer perspective as well as overviews of the BU Versions and BU Section Editing plugins. Along the way, various insights will be shared that provide a window into how BU has built an effective content management system on top of WordPress.

For more information, visit the WordCamp Boston 2012 website.