The death of technical writing, part 2

In my last post, I suggested a few reasons why technical writing is dying. And it is, at least as a career with a single focus on writing documentation for end users.

What’s happening, and what do we need to do?

Continue reading “The death of technical writing, part 2”

The death of technical writing, part 1

For a few years now, I’ve been worrying about the future of technical communication as a career. Not that user docs will disappear (as much as most people might want that), but techcomm as a unique job title, as opposed to one of many tasks that someone might have. I remember hearing Noz Urbina telling us that we were doomed, back at Lavacon 2012. And I attended a few webinars at that time that were also very negative about future prospects.

They’re right: We’re doomed. Pack up your pens and find another use for that English degree.

Continue reading “The death of technical writing, part 1”

Fast. Good. Cheap?

I usually work in a tactical writing mode: documenting new features and workflows in an agile development environment, or writing special content for training or specific customer requirements. I’m very comfortable working at a tactical level. But in the iron triangle of fast/cheap/good (where you can pick any two), going for fast/good incurs a cost that’s very easy to miss for a while: losing sight of the strategic goals…or failing to create them at all.

Continue reading “Fast. Good. Cheap?”

A few ideas and one scandalous revelation

My last post was number 25 (sorry about missing a week). That means that I’ve been posting for 6 months (I missed a week). My goal is to reach 100 posts and then…well, I’m not sure. If my posts by then are “let’s look at the things on my desk and make them metaphors for technical writing,” then I’ll pack it in. But now that I’ve hit a round and arbitrary number, I’m going to write down some ideas and plans. And I’ll reveal Shocking News!

Continue reading “A few ideas and one scandalous revelation”

In search of the perfect (or perfectly adequate) writing tool

Everyone who uses tools for a living loves their tools. And has strong opinions about them. Most programmers are happy to talk about their favorite coding languages and development tools, for example. For tech writers, we get to argue about content management systems, authoring tools, authoring formats, documentation structure…And that’s after we’ve battled over grammar, font choice, and glossary terms. Seriously: Glossary battles are the worst.

Now I find myself needing to change my writing process, and probably adding a tool or two to my workflow. Oh joy.

Continue reading “In search of the perfect (or perfectly adequate) writing tool”

What did I expect to get from conferences?

I really like Tom Johnson’s recent interview with Pawel Kowaluk, who is organizing a techcomm conference in Poland. After a much appreciated compliment, he explains that he’s trying to include topics that show how techcomm is a vital component of a company’s business practices, and not an afterthought, a bolted-on requirement that gets included because it’s just how things are done.

Which is what I’ve been trying to get to, and why I keep wandering around the point of why I think techcomm is important. And also why I’ve been frustrated when conferences become advertisements for tools or specific processes, without really explaining how we make the business case for our existence.

Continue reading “What did I expect to get from conferences?”

What I’ve learned in a week (and a bit longer than that)

After the great response to my previous post, I should probably write another post about something else that tech writers are doing wrong. And although there is a part of me that would love to write a purely contrarian article for the hell of it (“Structured writing: Threat or menace?”), the responses to my post were so intelligent and reasonable that I need to focus on positive contributions.

Continue reading “What I’ve learned in a week (and a bit longer than that)”

I don’t get conferences

I’ve been over-analyzing the process I use for content creation. In fact, it’s pretty simple, and the requirements are low. I don’t require a lot of technical overhead to create documentation for my company, and that includes written content, videos, screenshots, and diagrams. And tags and links and comments and a bit of organization.

I’m not creating a set of manuals, or building in-product help. (Not yet, anyway.) Which is what the majority of tech writers do, and I think that’s why I don’t get a lot of value out of most tech writing organizations and conferences.

Continue reading “I don’t get conferences”

Ratings, comments, and collaboration

A requirement for any documentation that I create is that readers can rate and comment on the docs. I’ve been publishing documentation to systems that support this for about 10 years now, with a short gap in there. Not every tech writer agrees that these are necessary, or even desirable, so I’d like to analyze my reasons for being so stubborn about it.

Continue reading “Ratings, comments, and collaboration”