A big part of a technical communicator’s job is research. The information we use to create content comes from a wide variety of sources: technical specs, product research documents, business proposals, white papers, internal wikis, customer support tickets…
And even from actual people. There’s lot of good info locked away in our coworkers’ heads. Getting to that info isn’t always easy, but I’m honestly surprised how often one question comes up both in interviews and in discussions with other tech writers: “How do you work with engineers?”
Continue reading “Working well with others”
While researching doc tool and process options, I’ve been interested in developments in DITA, especially a call for simplified DITA. I’m just surprised that it’s taken this long to get started. But I’ve seen at least one DITA expert say that simplified DITA is good for engineers and other transient contributors. Again, people are stuck in the mindset that only professional technical writers can write “correctly,” and we’re doing everyone a favor by allowing them a peak into our walled garden.
But here’s the thing about DITA, and structured writing in general: It commodifies technical writing. And while that might not be a bad thing, we have to acknowledge that if we go to a fully-structured writing world, one of the consequences is that we turn tech writing into a commodified skill, making it easier for everyone to write acceptable documentation.
Continue reading “Structured writing = commodified writing”
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”
I don’t usually create resolutions for the new year. It just wasn’t a thing that I, or my family or friends, ever did. But I’m working on my annual goals for work, and it got me thinking about professional development, and what I can do about that in 2014.
I’ll try to create a list that’s fairly realistic, but I’m still going to organize these goals by the likelihood that I’ll actually get around to them.
Continue reading “2014 Resolutions”
Although “collaboration” is a buzzword, it’s also a worthy goal for any tech writer. Or customer support agent. Or customer success manager. Or pretty much anyone, to be honest. I’ve known more than one tech writer who was happy working alone, receiving technical specs from engineers and throwing docs back. But those jobs: a) aren’t much fun; b) aren’t going to help you build your department.
Or your career.
Continue reading “Collaboration: What’s in it for Me?”