Documentation Driven Development

| tech | conferences | writing |

Last week I went to Heavybit Dev Guild and learned about designing for developer experience (DX). This was the first time I had heard of the term DX used, but of course it makes perfect sense. All of the Heavybit companies (including CircleCI) are focused around creating developer tools. Naturally when you are creating tools for developers the types of things that make those tools useful and a joy to use are very different than when your primary audience is the mass consumer market.

All of the talks were great, and I am pretty sure that they will be posting videos of the talks here so keep an eye out for that. Three things really stood out to me:

First, during the opening remarks, Jesse Robins talked about how developer tooling changes the culture of an organization. If you want to change the culture of an organization then its not enough to just build a product, you have to also build a movement.

Second, during a Product Discovery Panel, Patrick Malatack mentioned that before Twilio writes a single line of code they write the docs first. We have heard of Test Driven DevelopmentBehavior Driven Development, and * Driven Development, but this is the first that I have heard about “Documentation Driven Development”. This is such an amazing idea that I would love to dig deeper into. So often documentation is just an afterthought. Good documentation (especially when you are working on a FOSS project that does not have “official support”) can make or break your platform. DDD makes a lot of sense when your product is primarily an API like Twilio, I suppose it could fall apart for other types of products. In any case, it is critical to periodically step into the shoes of a brand new user and go through your documentation.

From a support perspective, there is nothing more annoying than getting 100 questions from a user who clearly didn’t even bother to read your documentation. But from a users perspective, there is nothing more annoying than reading documentation and finding out that the person that wrote it has not looked at it in three years because nothing works. In short, if you want your users to RTFM, make sure the FM is worth reading.

Lastly, during a founders panel that discussed building vibrant developer communities. Matt Debergalis talked about how when they first started Meteor they tried to follow an Apple model when it came to product design decisions. He stated that:

Apple Model does not work in FOSS, since you don't control your own product. People are gonna show up with not just feedback, but also code.
Overall, this was a great event. I am looking forward to the next one. Huge thanks to HeavyBit for making this happen.

Thank you for reading! Share your thoughts with me on mastodon or via email.

Check out some more stuff to read down below.

Most popular posts this month

Recent Favorite Blog Posts

This is a collection of the last 8 posts that I bookmarked.

Articles from blogs I follow around the net

Today in heavy-handed metaphors

Sam Altman is the owner of a massive, invasive, parasitical toxic sludge that respects no boundaries and ruins everything it touches, and that he thinks someone else should clean up. Also his new house has mold. OpenAI CEO's $27 million San Francisco ma…

via jwz July 19, 2024

Weeknotes: GPT-4o mini, LLM 0.15, sqlite-utils 3.37 and building a staging environment

Upgrades to LLM to support the latest models, and a whole bunch of invisible work building out a staging environment for Datasette Cloud. GPT-4o mini and LLM 0.15 Today's big news was the release of GPT-4o mini, which I wrote about here. If you build ap…

via Simon Willison's Weblog: Entries July 19, 2024

ESM3: A simplified primer to the model's architecture

A short primer explaining the architecture of the ESM3 model

via Emmanuel Blogs July 18, 2024

Generated by openring