"Plain English is the discipline of choosing the simplest word that carries the full meaning. It doesn't reduce accuracy. It reduces the cognitive load required to extract accuracy from the text."

https://www.linkedin.com/pulse/plain-english-being-understood-across-time-zones-carrie-warner-wsc1e/

#Writing #Language #TechnicalCommunication #Technicalwriting

Plain English is about being understood across time zones

Writing principle: Plain language for global audiences Plain English gets resisted in technical documentation for one consistent reason: people conflate simplicity with imprecision. If it's easy to read, it can't be rigorous.

Even with AI providing significant assistance in technical writing, it remains important to aim for content that is as low maintenance as possible.

#TechnicalWriting #AI #ContentStrategy

Weeks of not writing, before I wrote a word — that's how I used to learn a product in regulated docs.
That time was in the budget. It's getting cut, and AI gives management the cover. The sentences come out cleaner; what disappears is the writer who becomes an expert in their own right.
The trap: AI makes context ownership more valuable, but you can't govern context you were never allowed to learn.
#TechnicalWriting #AI
https://open.substack.com/pub/stevearrants/p/you-cant-govern-context-you-were?r=5qqjk8&utm_campaign=post&utm_medium=web&showWelcomeOnShare=true
You Can't Govern Context You Were Never Allowed to Learn

The same budget that made writing faster is producing writers who can't do the one job AI makes valuable. We're putting the pieces together without understanding the whole.

The Way We Write Now

Hey people in the #UnitedStates, is it worth applying for jobs on #LinkedIn? Specifically in #TechnicalWriting, #Proofreading, and Document #formatting?

I have not heard good things.


#UnitedStates #LinkedIn #TechnicalWriting #Proofreading #formatting

Hey people in the #UnitedStates, is it worth applying for jobs on #LinkedIn? Specifically in #TechnicalWriting, #Proofreading, and Document #formatting?

I have not heard good things.

As a former tech journalist, I wholeheartedly agree with this!!

"A tech writer is that person who, like a seasoned reporter, chases the product news and presents it, making sure that they’ve collected the strongest evidence. It’s a matter of persistence. Like a particularly learned bulldog, the human writer won’t let go of the news: it’s theirs to bring past the finish line, which means going live, even if the outcome is rough around the edges. DevRels, once shunned by tech writers, are being vindicated in that their humanity is the only thing that can stand out in seas of slop.

For years, we have complained about being treated like formatting factories or syntax janitors. Now that AI is taking those tasks off our plates, and with them a certain comfort zone, we seem afraid to admit that our work is about chasing truth and providing fellow humans with direction. We are in the business of empowering people to build incredible stuff through AI, not that of sticking sentences together in files and chunking content using some dialect of XML. We can no longer hide behind chores: it’s time to guide."

https://passo.uno/tech-writing-role-split/

#AI #GenerativeAI #TechnicalWriting #AIAgents #SoftwareDocumentation #TechnicalCommunication #Docs #LLMs

Feed the machines, then guide the humans

Docs as code used to mean editing docs as if they were code. Today it also means that docs have become executable, either as agentic instructions, skills, or context for large language models. Tech writers must now ensure that the reference and procedures they’ve carefully written and edited are the best possible fuel for AI, lest they jam the machine or make it stray into dangerous territory. Humans have their own needs though. Who feeds them?

I finally made the switch to Opus 4.8 with minimal effort. Previously, using Opus 4.7 for technical writing tasks consumed tokens at an unsustainable rate. Now, with the same workflows and likely some fine-tuning by Anthropic, I managed a heavy load of documentation requests this week. Token consumption is now much more manageable.

#AI #TechnicalWriting #Efficiency

"An engineer named Siddhant Khare wrote recently about what he called “AI fatigue” — the exhaustion that comes not from creating but from reviewing. Before AI, his day had a rhythm: think about a problem, write code, test it, ship it. After AI, his day became a loop of prompting, waiting, reading output, evaluating output, deciding if the output was correct, deciding if it was safe, fixing the parts that weren’t, and re-prompting. He described it as becoming a quality inspector on a conveyor belt that never stops. The work was faster but emptier. The flow states that used to sustain him — the deep, energizing focus of building something yourself — had been replaced by the shallow, draining focus of judging something you didn’t build.

Not every writer experiences this the same way. For some, the shift is actually liberating. If your day job involves writing yet another SDK migration guide or documenting the fine-grained differences between configuration parameters across product tiers — content you won’t remember in a month — there’s no loss of creative joy when the machine drafts it for you. You become the editor, not the author, and you save your real creative energy for work that matters to you personally. The fatigue isn’t from reviewing; it’s from pretending that all documentation deserves the same emotional investment. Some of it is toil, and outsourcing toil is fine.

But here’s the tension: if you stop caring about the work the machine produces, who maintains the quality? This is where the concept of ownership becomes critical. The tech writers who thrive in this landscape aren’t the ones who wait for engineers to hand them drafts to edit. They’re the ones who own the reference documentation, who run diffs against every API release, who update architectural diagrams, who maintain a single source of truth..."

https://idratherbewriting.com/blog/judging-beautiful-docs-ai-fatigue-podcast

#TechnicalWriting #AI #GenerativeAI #SoftwareDocumentation #TechnicalCommunication #Docs #Programming #SoftwareDevelopment

Judging beautiful docs, AI fatigue, and tool slop

In this podcast, I chat with Fabrizio Ferri-Benedetti about a variety of topics related to AI and docs, such as applying Italo Calvino’s literary principles of lightness and quickness to evaluate docs, the reality of AI review fatigue versus creator fatigue, whether vibe-coded tools are tools slop, developing internal skills for repeatable doc processes, and the utility of running local AI models.

I’d Rather Be Writing Blog and API doc course

First-time speakers are warmly encouraged, especially if you’ve done useful docs work but haven’t spoken about it publicly before.

Submit a proposal even if you’re still shaping the talk. We’d be happy to see the idea early.

#IndiaFOSS #WriteTheDocs #TechnicalWriting