How BTD will change my approach to technical writing

The biggest takeaway from Beyond the Docs is that understanding how tools are built changes how I think about documenting them.

Before this project, I mostly approached documentation from the perspective of what users need to know. What information is missing? How should it be structured? Where might someone get stuck?

Building the tools myself gave me a different perspective. I had to make the technical and design decisions that I would normally encounter after the fact. I experienced the constraints, tradeoffs, and workflows that shape the products I document.

Now, I don't expect this experience to turn me into a software engineer. That's not the point.

The point is that I can now approach technical writing with a better understanding of what happens before the documentation exists. I can ask better questions about why the product works the way it does, recognize where documentation can help, or recognize when the product itself may need to change.

I could see myself asking questions like:

• If we change the response structure for this endpoint, how will customers be affected?
• This function requires a lot of fields. Are they all actually necessary?
• What information belongs in the default output versus an optional verbose mode?

Now these aren't questions I couldn't have asked before embarking on this project. But I think that now I have more context for why they matter.

Beyond the Docs is still a work in progress, but this first version has already changed how I think about technical writing and the developer experience!