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.6K
active users

#technicalwriting

2 posts2 participants0 posts today

"[W]hat we are doing is shepherding AI, limiting it to certain contexts. We are learning where it’s best to call it, how is best to feed it. And what to do with the output. So is it looks very much like an editorial process, an editorial workflow where you provide some initial input, maybe some some idea on what content to produce, then you review it. There’s always that quality assurance, quality control side, the supervision.

AI is not really autonomous. It relies a lot on us. And I feel like sometimes there are days where, when coding through AIs or doing some assisted writing, I’m spending more time helping out the AI doing the actual task that I’m asking the AI to do. But I take this as a learning process. I read this article the other day, Nobody knows how to build with AI yet. And it was a developer saying that they haven’t quite figured out how to best work with AI. There were lots of comments around the fact that you have to spend lots of time, you have to learn how to talk to it, and when the model changes, you have to also maybe change something you’re doing. You have to learn how to optimize your time. But your presence is always mandatory.”

passo.uno/webinar-ai-tech-writ

passo.uno · Webinar: What's Wrong with AI Generated DocsToday I discussed how tech writers can use AI at work with Tom Johnson and Scott Abel. It all started from my post What’s wrong with AI-generated docs, though we didn’t just focus on the negatives; in fact, we ended up acknowledging that, while AI has limitations, it’s also the most powerful productivity tool at our disposal. Here are some of the things I said during the webinar, transcribed and edited for clarity.

"While haste and speed often get confused, they differ in that the second shows control instead of panic. You can maximize speed while keeping accuracy quite high; beyond a certain point, though, spending more time on accuracy, style, or other aspects that prevent a document from going live always yields diminishing returns.

Nobody reads perfect yet outdated docs, except historians. Even then, docs aren’t perfect, because documentation can’t ever be perfect. This is a key principle I stand by (call it the Ferri Paradox if you want): Any document describing a system is necessarily inaccurate. And yet, this reality doesn’t significantly alter the impact of our work, because we aim for simplicity and usefulness over extreme faithfulness. Given how imperfect products are, docs are a charitable portrait.

Now, how you write docs quickly depends on a number of factors. Some of those factors you can’t control: your overall amount of experience as a writer, your initial expertise with specific technologies, and the way features are developed and released in your organization. But other aspects are yours to act upon. For example, you can decide how to best use the technical resources at your disposal and how to approach writing the docs and asking for feedback."

passo.uno/how-write-tech-docs-

passo.uno · How I write docs quicklyI’ve been writing documentation and technical articles for more than a decade now. One piece of feedback I consistently got from managers and peers during all these years is how fast I am when producing and releasing docs. For example, I was once asked to document a new feature from a team I wasn’t serving two weeks ahead of launch. Everything was new to me, but I had most of the docs drafted after four days. By launch, the docs had been deemed ready to go live.

Basic Questions That Every (Technical) Writer Should Try To Answer - AKA Technical Writing 101:

I assure you that If you can answer all of these questions, your readers won't mistake you for a chatbot :)

1. What is the purpose of the document that I'm writing?

2. Why am I writing this document?

3. Who is the target audience of this document?

4. Is this document part of a series of documents?

5. If so, have I established a nexus to the other documents in the series?

6. Are there any predefined formal requirements that the document must meet?

7. Does the document meet those requirements?

8. Does the document include an introduction?

9. Does the introduction clearly explain the purpose of the document to the target audience?

10. Does the introduction present the topics that will be explored in the body of the document in a straightforward way?

11. Does the document include a conclusion?

12. Does the conclusion provide a good summary of the previously explored topics?

13. Does the conclusion tell readers what they should have learned by following the document?

14. Does the body of the document include use case scenarios based on user personas that explain the potential advantages of adopting the explored tools or methods?

15. Does the body of the document depict real-life examples of how readers can immediately start using the tools or methods explained in the document?

"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...)