I have been working with a team to build a time machine. Yep. A time machine. It can travel to the past. It can return to the present. It can’t really go into the future yet, but I have confidence we’ll get there eventually. 😉 This time machine has another caveat: It only works for WordPress websites. We have a ways to go before our time machine can recover my lost pog collection.

While building this time machine, we discovered just how important it is to communicate clearly. I think it’s time to document some of the techniques we are now using for discussion and collaboration.

Rules for discussing time travel (among other things)

1. If someone is unclear, ask them to rephrase

Discussions when building the web can often become cluttered with industry jargon, acronyms, and harder to grasp concepts. For example, these terms regularly come up in our time machine discussions: API endpoints, ES (Elasticsearch), Jetpack syncs, events, discarded events, rewind, backups, timeline, alternate timeline, cloning, clients, PR (pull request), DBOs (Database Objects), and many more. If you don’t know what any of those are, that’s totally fine. I have only a vague high-level understanding of some of those myself.

Occasionally, when discussing the time machine, some combination of those terms require clarification. So I ask. Even if I think I understand what one of our brilliant developers is asking, I want to make absolutely sure so I don’t accidentally lead them down the wrong path with the design. I also want to make sure they are getting accurate information. When in doubt, ask for clarification.

Another method of clarifying is to rephrase what you heard to make sure it matches what was said.

2. Agree on shared terminology

A few weeks ago, we needed to come up with a term used for events that show up in a timeline, but are no longer on the WordPress site. This is different than something that is deleted because we still have and still display the data for the event. We keep these around to let folks restore the events at some point in the future. In the mean time, these events are no longer a part of the live site or its database.

There were many iterations of what this kind of event was called. Folks were using all sorts of creative ways to refer to this event. It was confusing. We needed to agree on a term. The most popular term among the developers was “nullified event.” Unfortunately, it’s not quite accurate and is confusing for folks not familiar with the term “null” so I proposed we do a bit more brainstorming. Here are some of the proposed names: terminated, shadowed, voided, hybernated, dormant, lurking, and zombied. Ultimately, we made the decision to go with “discarded events” because it’s a word that paints a pretty accurate picture of what is going on. The event is just being set aside while the rest of the events are still in play.

Once we agreed on a term, our conversations around this type of event were much smoother. It also helps that the term painted a pretty good picture of what was happening for folks not up to date on our time travel lingo.

3. Use phrases that help folks understand

If you name a project or piece of UI internally, at some point the name is likely to be used externally purposefully or otherwise. It’s important when you’re coming up with terms like “discarded event” to consider how well they convey the idea to folks new to the project or folks using your product. We took this into account when choosing “discarded” over “nullified.”

In addition, when you’re naming projects, try to name them something that makes sense as an external project name. Not all products or projects are referred to externally, but if there is an internal name that’s different than the external name, folks are bound to be confused in discussions that refer to both. Also, if you change the name later, folks at your company will be confused since they may not be sure if you’re referring to the same project they worked on back when it kicked off.

Okay enough with rules! Back to time travel!

Our time machine is just about ready to make a public appearance. Pretty cool, right? Except it’s not even the coolest part of what we’re building. It’s just a byproduct of a larger, more interesting project predicted to unlock all sorts of nifty tools for your websites.

If you’re still curious about what we’re building, keep an eye on Jetpack and watch Matt’s keynote at WordCamp US. Maybe our time machine will make an appearance.

#remote-work

Posted by Michael Arestad

I design at Automattic.

2 Comments

  1. I’m commenting on this post from the future. Great job establishing the ground rules for time travel. It’s working great!

  2. […] The language of time travel / Michael Arestad […]

Comments are closed.