Passing the Baton

On or around the 21st of August, my family and I will welcome a baby boy, officially making me the luckiest man in the world. That also means I’ll be taking off from work for a bit, as I tend to my new highest priority.

Until that time, and for the past several weeks, I’ve been working hard to ensure that I will be unnecessary in my absence; basically making sure that the projects that I’ve been involved with are properly documented, handed over, and generally in a good place.

My friends jokingly call this process the “hit by a bus” test. Which means whatever project you’ve been working on should be able to proceed forward in case you were… well, hit by a bus. A less grim way of looking at this, is that this process is simply good practice. If your work is documented, built, structured, and thought through in a way so that anyone can follow your line of thinking and continue your work, then you’ve probably done good work.

The WordPress editor focus has had my full attention. I’ve written about it in the past, but the all-encompassing goal is to bring a new post and page building experience to WordPress, that uses blocks to unify multiple different interfaces into one. It’s been difficult work, but the potential is quite huge. We just released a rather major 0.8 release which I’m particularly excited about, because it now has nearly all the ingredients necessary for it to be evaluated holistically as a product, even if it is still unfinished, unrefined, unpolished.

The editor is called “Gutenberg”, and it was important that two things were in place. First and foremost, the project has a new design lead. Tammie is an amazing designer with great communication skills, she’s going to be perfect for the project. I look forward to return to Gutenberg in a designer capacity — that is what I do best. With Tammie at the helm, Gutenberg can keep up its high speed of weekly releases, without having to wait.

Secondly, it was important that as much of the design philosophy that got us to where 0.8 is today, was documented in as much detail as possible. I tried to do this in a substantial update to our design document.

At a high level, the design doc has a number of purposes:

• Parse the kickoff goal into specifics, to help define and also narrow the scope of the project
• Explain why we are building a new editor, and implicitly what a new editor needs to be able to accomplish
• Go into the vision of how to accomplish the what and the why
• Provide a vision for where things can go in the future

In addition to this, the design doc features blueprints that label each major section, so we can all use the same vernacular, as well as a “best practices” for designing blocks.

While the design doc is living — such a thing should change and adapt — it can also hopefully serve as a breadcrumb trail of ideas, one leading to the other, and help a reader understand the path taken. Perhaps even suggest where to go next. Good design has gravity, and the more you work on it, the more gravity it gets. At some point, the pieces start falling into place on their own. Hopefully the recent design doc update added a little more gravity.

Making sure you pass the “hit by a bus test”, isn’t about making any one person expendable or unnecessary, quite the opposite: it’s about inclusion. It’s about realizing that even if you spent 7 months dreaming about this one project, it’s bigger than just one person. If you love something, set it free.

Editorial note: There is a companion post to this titled ‘Receiving the baton‘.