Posts on passo.uno

Whoever speaks badly, thinks badly and lives badly.

I’m seeing more instances of docs and README files addressing agents directly, as in “Hey, if you’re an agent, follow these instructions”.

A friend of mine recently lost her job in a layoff.

While chatting with Sarah Deaton about the formats agents could use to talk to each other, we got to questions that might sound obvious: why should machines (say, LLMs) communicate with each other like we do?

Docs as code used to mean editing docs as if they were code.

In my predictions for 2030 I wrote that tech writers would be using specialized LLMs, running locally on powerful hardware.

Back in 2024 I wrote that AI helps me remove boring work at the margins.

AI is inflicting a proliferation of tools, in the utensils’ sense.

Docs are often thought of as a purely functional artifact, a packet of content that, when it works, it’s not remembered at all.

Three years ago I published a high fantasy map of technical writing.

If someone asked me to set up a team in charge of software documentation, I would not hire for specific roles or cookie-cut job descriptions.

Not a month goes by without someone claiming they’ve killed tech writing.

At the end of The writing was always the cheap part, I alluded to the fact that tech writers need to pick up new habits and skills, but didn’t dig into what that entails.

Last December, quite unrealistically, I took a solemn oath: I would not write again about AI for at least another year.

I like cooking recipes.

Hey you, Yes, you, who are thinking about not hiring a technical writer this year or, worse, erased one or more technical writing positions last year because of AI.

Instead of writing my tech comms predictions for next year like I did in 2024, I’ve written a fictionalized account of my day as a technical writer in 2030.

Code Wiki, a new AI tool by Google, claims to generate a complete set of docs, including diagrams, from code repos.

The dam of AI-written doc contributions might be about to break.

If you’ve been following the AI space for a while, the MCP acronym might be a familiar sight: it’s an open standard for connecting large language models (LLMs) to tools and data.

You might have read Annie Mueller’s post poking fun at developers’ tutorials.

I sometimes lurk on /r/technicalwriting to gauge the interests and sentiments of the community.

Docs are a product.

I’ve been noticing a trend among developers that use AI: they are increasingly writing and structuring docs in context folders so that the AI powered tools they use can build solutions autonomously and with greater accuracy.

I’ve been writing documentation and technical articles for more than a decade now.

Strategy, Michael Porter wrote, is choosing what not to do.

This last weekend I created another LLM-powered tool, Impersonaid (all puns intended).

A colleague recently asked how I find time to blog about technical writing after hours.

We all want to do a good job.

While some developers wrinkle their noses at the sight of Copilot and similar AI-powered tools, tech writers find them to be great sidekicks.

I’ve recently upgraded some of the hardware I use for work and leisure, so it’s a good time to refresh my list of tech writing gear.

In what is tantamount to a vulgar display of power, social media has been flooded with AI-generated images that mimic the style of Hayao Miyazaki’s anime.

Demoralized by the advent of LLMs, I see tech writing communities break ranks and flee.

The part of my brain that rages against injustice stirs like a slumbering dragon when I read the words “Native English”.

This past weekend I’ve been experimenting with AI-assisted coding to port basic docs-as-code elements to old operating systems and platforms, such as the venerable Intel 386.

Writing for LLMs is the new SEO obsession.

I think all technical writers, at some point or another, feel the urge to base their work on something more systematic than “it’s just the way folks documented stuff since forever”.

For the first time since I started this blog, I’m writing some predictions on software technical writing for next year.

I’m a terrible user of documentation.

Everybody loves to hate Frequently Asked Questions, or FAQs.

A reader asked me how they’d become a Documentation Engineer, because they saw I got hired as one and felt curious about what it takes to get there.

I’ve been using large language models (LLMs) for a while now.

I’ve recently started a new job as a documentation engineer.

I’ve recently found out about TypeSpec, a new language aimed at describing web APIs, through an interview that bears the provocative title of API Design in the Post-OpenAPI Era.

What does it mean to fail as a technical writer?

Congratulations!

I’ve recently become a docs maintainer for OpenTelemetry, a pretty big open source project.

Just around the time I was complaining about the scarcity of books on technical writing, I got a copy of Technical Writing for Software Developers by Chris Chinchilla, a regular of the Write the Docs community.

With the job market getting tougher by the day, there’s a rising belief among tech writers that their role is “too niche” and a “dead-end job”.

People usually say that I’m a pleasure to work with and that I’ve a highly collaborative spirit.