As temporary as an elephant ear

When I saw the truck going the opposite direction, it made me want to cross the median and follow it wherever it was going.

Summer in the United States means fairs and festivals. These events only last a week or two. Carnival rides, games, and fried food booths are built and deconstructed during that time.

While driving home from California, we saw one of these fair fixtures. It was being hauled on a trailer, headed somewhere we weren’t. On the side of the decorated booth were two large words:

ELEPHANT EARS

I love a good elephant ear. I even love a bad elephant ear. These things are flattened dough, fried, then covered in cinnamon sugar. What’s not to love?

One downside of elephant ears is they disappear quickly. Sort of like the fair where they’re consumed, elephant ears are temporary.

This build-it-up-and-tear-it-down pattern makes sense for short-term events. That elephant ear booth we saw on the highway likely had a day or two between completely separate events.

By contrast, developer products are expected to be permanent.

Just about weekly someone sends me a documentation link hosted on Notion, Google Docs, or another location that feels impermanent.

Usually this documentation starts as an early preview. In fact, some have told me they want it to seem temporary. They don’t want anyone to build permanently on something that could change.

Unfortunately, if documentation feels temporary, many developers won’t give it a further look. Much of developer experience is to build trust. When you’re committing code (and the time to plan and write the code), you want to believe it will last.

Your “minimum viable docs” aren’t too viable beyond developers who already trust you.

Increasingly, I’m seeing these “temporary” docs linked in navigation, which shows how easy it is for beta documentation to become production documentation.

There are many tools and frameworks to help you find a semi-permanent location for your new documentation. With slightly more effort than a Notion doc you can gain trust from your earliest developers.

Here are three steps to get started:

1. Set up docs.developerproduct.io sub-domain
2. Point GitBook or Slate on Netlify to your sub-domain
3. Remember you can always change it later

​

Are there other, better documentation choices? Yes! But the idea is to get started in a way that looks more permanent than a throwaway page.

With this minimal start, you’ll future proof your docs choice, which means devs will feel your commitment to the product.

Elephant ears are tasty and meant to be temporary. Your docs can be tasty and permanent.

If you’d like fresh eyes on how your developer experience feels, see how to work with EveryDeveloper.