techhub.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
A hub primarily for passionate technologists, but everyone is welcome

Administered by:

Server stats:

4.8K
active users

#technicalwriting

1 post1 participant0 posts today

"The purpose of documentation is to skill and empower someone in their craft. It serves their acquisition and application of skill.

I have heard it suggested that documentation should now be optimised for consumption by AI. That is like asking how we can make our cities better for cars, or our workplaces better for the furniture.

If creators of documentation are prepared to sacrifice its human purpose in order that LLMs can more effectively slurp it up and regurgitate it on demand, then they have meekly accepted values that more properly belong in a dystopian horror story.

Even if we think about the notion only pragmatically, leaving all values aside, it’s a panicky, inconsidered idea. What possible sense does it make to try to “write for LLMs” when LLMs themselves are evolving so rapidly that their capacities and patterns change from one week to the next?

Human beings are difficult creatures with complex needs, but they have been that kind of creature for thousands of years. Not only have we painstakingly built up deep understanding of them, we are them; we can know them from the inside. A good way of writing documentation for human beings today will still be a good way to do it in a few years’ time."

vurt.org/articles/my-favourite

vurt.orgMy favourite German word - Daniele ProcidaIf creators of documentation are prepared to sacrifice its human purpose in order that LLMs can more effectively slurp it up and regurgitate it on demand, then they have meekly accepted values that more properly belong in a dystopian horror story.

“The goal from starting out is to be able to create an API documentation suite from scratch. The minimal viable document, or the minimum the document must contain before it’s released, includes having all the calls covered, a description, even if only one sentence at this point, for every field and call, section overviews, call examples, and examples of each field. I suggest also creating a Postman collection file for each API suite. A Postman collection file is a complete set of all the requests and that each request may be run by clicking it; it’s a convenience to clients.

Being able to create that document indicates the writer’s proficiency in the mechanics of API documentation. There is a sense of accomplishment when achieving this and comfort with this process. And rightly so. They have the privilege now of calling themselves API documentation writers.”

robertdelwood.medium.com/start

Medium · Starting API Documentation Writers: Obstacles To Watch Out ForBy Robert Delwood

"What are docs for AI agents? How are they different than internal eng docs? Do we really have to maintain the agent docs and eng docs as separate docs sets? This page contains my notes on these questions.

Scope:

I work on developer docs i.e. docs for software engineers. I don’t know how relevant AI agents are for technical writers in other industries or domains.

I’m thinking specifically about docs for AI agents. I’m not sure that an all-encompassing “docs for AI best practices” exists. The way that we optimize docs for RAG-based chatbots (for example) is probably different than the way we optimize docs for AI agents."

technicalwriting.dev/ai/agents

technicalwriting.devDocs for AI agents

My first video on YouTube for The Technical Editor.

"Stop Explaining Things Wrong—Do This Instead"

Most engineers skip the #1 rule of technical communication.
Spoiler: It’s not about what you say, but who’s reading it.

youtu.be/CU82YLMcLpU

youtu.be- YouTubeEnjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.

"Among the many forms of yak shaving that plague our craft is obsessing over documentation tooling. The more technically minded among us are guilty of spending too much time tightening the screws of some CI pipeline just to save a few seconds when building the docs. As exercises, they’re indeed useful, for they help us practice technical skills that might lead us to becoming docs engineers. Should we park writing the docs over picking static-site generators though?

The danger lies in mistaking the motion for progress. A perfectly tuned pipeline that builds no new useful content is a monument to wasted effort. It’s the equivalent of a chef who spends all day sharpening their knives to a razor’s edge but never actually cooks a meal. The knives are essential, but they are not the dinner. Our tools are essential, but they are not the documentation. The user who is stuck at 2 AM with a failing API call does not care about your elegant build process; they care about finding the answer."

passo.uno/things-tech-writers-

passo.uno · Things technical writers shouldn't care about... yetStrategy, Michael Porter wrote, is choosing what not to do. Now, the problem with knowledge work such as the one tech writers carry out is that it’s full of things that seem to require equally important, time-consuming decisions. While engaging in lengthy disquisitions might be alluring, endlessly combing the Zen garden of theory doesn’t solve the basic problem of the docs hierarchy of needs, which is writing the damn docs and making sure they’re accurate, useful, and easy to follow.

(To the tune of ABBA’s Money, Money, Money)

I write all night, I write all day, to craft the guides they toss away.
Ain’t it sad?
But praise is cheap and tickets close, for all this thankless, perfect prose.
That’s too bad.

A new feature ships, all sleek and grand,
But no one seems to understand.
I wouldn’t be writing docs at all;
I’d fool around and have a ball.

EDIT: Thanks all!! I'm passing along your suggestions.

Anyone know an open-source project, even a small one, that needs API docs created or improved? Asking for a #technicalWriting pro who wants more experience with API documentation. #FOSS #techcomm (bonus points if it hits interests like politics, food, beer, auto racing, mapping/OSM, civil engineering, social good...)

"Our biggest challenge as technical writers is bridging the gap between the tech we document and the users trying to understand it. LLMs provide us with the support we need to build that bridge. But it’s more than just a bridge to the user; it’s a mirror for the self. Running a draft through an LLM allows me to remix, rewrite, and truly understand what I’m trying to say. I’m not mindlessly generating with AI; I’m thinking through AI. It’s the writer’s equivalent to rubber duck debugging.

The tools we build using LLMs also allow our words to materialize as direct product impact and socialize our thoughts inside organizations. Think of the typical debates over a confusing user interface. Before, I used to argue based on my own expertise and intuition. Today, I could say, “I ran our docs through Impersonaid and it got stuck at this exact step. Here’s the full transcript.” Suddenly, my argument becomes a reproducible linguistic experiment"

#AI #GenerativeAI #TechnicalWriting #SoftwareDocumentation #UserPersonas #LLMs #Chatbots #SoftwareDevelopment #TechnicalCommunication

passo.uno/thinking-better-thro

passo.uno · Conjuring digital companions: How I'm thinking better through AIThis last weekend I created another LLM-powered tool, Impersonaid (all puns intended). It’s a docs user simulator: you provide the URL of a document (or its Markdown source), select the virtual persona, and start a conversation about the content. Right after I released it, I realized that I had been talking to an imaginary friend to create more fictional interlocutors to interact with. It’s not as bad as it sounds, though. In fact, I would argue this is what writers are meant to do.

We’re thrilled to welcome Prince Onyeanuna and Ezinne Anne Emilia to the stage!

They’ll be sharing their unique journey and insights in "Contributing to AsyncAPI from a Technical Writer’s POV."

From words to workflows, discover how documentation plays a powerful role in open source success. Don’t miss this session if you're curious about non-code contributions!

🗓 July 18–19
📍 Lagos, Nigeria
🔗 conference.asyncapi.com/venue/

"How to leverage documentation effectively in Cursor through prompting, external sources, and internal context

Why documentation matters

Documentation provides current, accurate context. Without it, models use outdated or incomplete training data. Documentation helps models understand things like:

- Current APIs and parameters
- Best practices
- Organization conventions
- Domain terminology

And much more. Read on to learn how to use documentation right in Cursor without having to context switch."

docs.cursor.com/guides/advance

CursorCursor – Working with DocumentationHow to leverage documentation effectively in Cursor through prompting, external sources, and internal context