How to use X at work

how-to-use-x-at-work.md

How to Use X at Work

Adapted from the wonderful original post: How to Use Elm at Work by Evan Czaplicki / 11 July 2016

Removed some Elm specific parts, and made Elm generic as X.

Trying X in some big JavaScript project is not very hard. Why try X like this? Well, tons of folks are trying out X these days, and as they share their experiences, I noticed that everyone who successfully introduces X at work tells the same story. They introduce X gradually into an existing JS project. The rest of this blog post outlines the typical success story in detail. What strategies work? What are some common mistakes? I hope this will be helpful for folks interested in using X at work or on their own!

Gradual Introduction

Every company that uses X in production follows a similar path:

1. Learn — Someone on the team starts looking into X. They build something on their own. They get familiar with X. They become the advocate. They “own” the remaining steps.

2. Experiment — That person writes one little thing in X at work to see how it goes. They do not have a massive migration plan or anything. They just do it.

3. Evaluate — If that experiment goes well, they do more. And if it does not go well, they revert it and go back to the other stuff.

4. Repeat — The person who introduced the original code helps everyone on the team learn X as it is used in more stuff.

Again, this is the success story. I hear it again and again from folks using X in production. I do not hear other stories.

This process works because it minimizes risk. Having an advocate means you have someone on the team who knows X really well. They can answer questions quickly in-house. Furthermore, you are trying something small in X. Maybe it is whipped up in a single day even. Point is, you are not pouring time and money into a project that may not work out. This means trying out X is really not a big commitment at all. Big upside, very little downside.

When you go through this loop the second time, I recommend expanding the section already written in X or trying something bigger on another page.

Fix a Problem

This broad outline is great, but it is important to be strategic in choosing your first project. Do not just write X code because you like it. Fix a problem.

There are two stories you can tell after rewriting code:

• “You know that crazy code that everyone fears touching? It is simpler now and I resolved some bugs.”

• “You know that code that was totally fine? It is different now.”

You want to tell the first story. In the ideal telling, the new version is better because of a particular detail about X. Not only is it better, but it is better in a way that can only be achieved with X!

The Checklist

The previous sections give you a flavor of what to do, but I wanted to make a checklist to make it more concrete. If you want to use X at work, make sure you are doing the following things:

• Have an advocate — There should be one person on your team who has experience with X on a hobby project. They drive the initiative and help team members with anything they run into.

• Start Small — It is best to introduce X gradually. Choose a small part of an existing project. Your first work project in X should not be a green-field project or high-stakes rewrite.

• Fix a Problem — Use X where it will really shine. X may be nicer for all sorts of stuff, but the best story comes when you resolve issues that hurt your team every day.

• Write X Code — You can talk a decision like this to death. What about this? What about that? Talking abstractly is a waste of everyone’s time. Write an actual chunk of X code. Evaluate it against an actual chunk of JavaScript code. Talk concretely.

Hopefully that helps you out!