"[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.”

https://passo.uno/webinar-ai-tech-writing/

*Pounds a liter of Gamer Supps*

FUCK IT, WE BALL!

*Quietly goes back to writing user manuals*
#TechnicalWriting

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

https://passo.uno/how-write-tech-docs-quickly/

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?

She is Still Looking For Work - Celeste Seberras, Tech Writer / Content Strategist / Developer Relations with a Infosec and entrepreneurial background. http://resume.hakr.gg http://lnkd.in/gYRfjTcB #AI #Blockchain #Infosec #Cybersecurity #TechnicalWriting #developerrelations

"[Techimabob-thingy] is powered by AI, so mistakes are possible. Review output carefully before use." Right. In decades of tech writing my experience proves folks are super careful & thorough when reviewing anything, esp. their "own" work.

I write software documentation for fun, and you can too!
https://documentation.libreoffice.org/en/join-the-documentation-team/
#LibreOffice #FOSS #TechnicalWriting

Elevate your communication skills and make your points impossible to ignore.

https://youtu.be/6h1LOb6Yw04

Red Hat Technical Writing Style Guide

https://stylepedia.net/style/

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

https://vurt.org/articles/my-favourite-german-word/

#Documentation That Developers Actually Read: The Netflix Approach - DEV Community
https://dev.to/teamcamp/documentation-that-developers-actually-read-the-netflix-approach-1h9i

My second video, which if I'm honest is probably the best advice I can give to any one on communication.

Tired Of Unanswered Emails? Try This!
https://youtu.be/bmm38OFzbVQ

“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.”

https://robertdelwood.medium.com/starting-api-documentation-writers-obstacles-to-watch-out-for-e0907610466f

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

https://technicalwriting.dev/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.

https://youtu.be/CU82YLMcLpU

Poor example to introduce the `disabled` HTML attribute:

Lesson: Don't use the same/similar name as the concept being introduced.

```html
<label>
<input type="checkbox" name="ch-box" value="disabled" disabled />
disabled
</label>
```

https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Attributes/disabled#examples

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

https://passo.uno/things-tech-writers-shouldnt-care-about/

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