Thursday, March 30, 2006

why i can't know everything anymore

| 0 comments |

I had an idea on the drive home that hints at my answer to Jeff Carr's question, "As technical writers, it seems we too often settle for being generalists. Perhaps we need to specialize more. What do you think??"

I was thinking about my interests in general and how these days it's really hard to keep up with the latest news and ideas about anything. When I was younger, lets mark this at the early days of the WWW, I was into a lot of different things. I still find the same topics interesting to this day: computers, music, technology, hard physical sciences, media, pop culture, the list goes on and on...

I loved to know a lot about a lot.

Fast forward 5-10 years, the present. I find it very hard to keep up with everything today, primarily because of how many people are engaged in the scene surrounding a unique focus. It's not necessarily the huge number of people, but that they are all connected via the Internet. Instantaneous knowledge transfer coupled with access for everyone who wants it is overwhelming us.

Because everyone can easily be an expert, i.e. the price of admission is an Internet connection, and you have to know more knowledge about a focus to feel merely competent, the bar has been raised for entry into the “I know a few things about X, Y, Z club.” Democratization of becoming knowledgeable in a focus also means that you are competing with endless numbers of experts, knowledgeable people, or even neophytes.

So I decided that even though it's hard, I have to reduce my interests these days because the time commitment required to being marginally involved in numerous focus scenes (even as a pure consumer) of information and knowledge would take up more hours of the day than exist. Keep in mind that I am married, and have my first child on the way!

Therefore, I think it is nearly impossible to be a generalist anymore. You could specialize your generality, but now I'm just playing rhetorical games :)

To tie this in, luckily when you go to work, the expectation is that you can handle a single job. But I think if you approach technical writing as a generalist, someone who can work in half a dozen fields, you will usually be passed over because someone out there has invested themselves more fully in a specialization than you have, whether by choice or luck.

In reality of course, a worker is also hired based on price, overall experience, ability to get along with the team, and a host of other criteria that have been around since the cube was invented. BUT, I don't think you should ever underestimate what a deciding factor specialized knowledge is when applying for a job.

I strongly believe that in some ways having a generalist's sense is a highly laudable technical writer attribute, but the speed at which business moves today mostly rewards "hit the ground running" ability over "grow with the company" ability.

Wednesday, March 29, 2006

comp sci 101

| 0 comments |

It occurs to me how important it is for a technical writer who works in the software arena to have experience with pseudocode. Not insomuch as you'd actually have to write your documentation with a description of the process in a psuedocode manner, but the advantage is that when you have the basic understanding of how applications step through logic, you're better poised to explain every detail to your audience.

It's fun when you get to piece together and interleave this hard logic with a matter-of-fact tone in your writing.

Thursday, March 16, 2006

Technical Writing Rule #24

| 0 comments |

Just because one Engineer says "it makes sense," doesn't mean it objectively makes sense to all people who understand standard written English.

Alternatively: If the author does not understand why something is accurate, then it's not accurate.

Monday, March 13, 2006

what do you do?

| 0 comments |

I'd like to post something and see what kind of agreement there is (that is if anyone is reading this).

In my mind, when you actually care, there are 3 discrete technical communication jobs:

  • Technical Writer
  • Technical Editor
  • Documentation [Expert, Specialist, whathaveyou]

Here's my definition of the tasks that fall under the purview of each title:

TW: Culling from design and planning documents, interviewing engineers / developers / marketers, and first hand use of the product, this person creates the documentation that accompanies the product as it goes to market. The technical writer’s main task is similar to the age-old assignment of writing a book report or essay; a topic is researched, learned, and then presented in the best possible format to communicate the issues to the reader. To me, the core value and skill a great technical writer brings to the table is knowing how to tailor a report/paper/procedures for the right audience.

TE: There's so much overlap between a technical writer and editor that the lines are very blurry. Ideally the TE assumes the standard editing functions such as ensuring clear and consistent style, visually, grammatically, mechanically, and substantively. Ideally (again), one can only become a TE after they have spent years as a TW. Only by gaining enough writing experience, would one be at the point where he or she can edit with authority.

On the other hand, it's feasible to understand the topics less than an expert, but still maintain the knowledge required to determine if the needs and style of the documentation is correct.

In a newsroom, you probably don't get to be an editor before you're the reporter. It's the same thing here.

It's my belief that a lot of TWs tend toward the editing side of things.

Documentation Specialist: Technically speaking, a documentation person is mostly concerned with managing documentation. These days, the job encompasses documentation organization, content reusability, and content delivery. This person rarely creates their own documentation; the documentation specialist is somewhat of a content broker.

Someone who is one with Frame maker for instance is a documentation specialist. This person probably spends the majority of their time writing frame scripts, tweaking styles, and setting up EDDs and other XMLy items. He or she has a keen eye for output to .pdf, HTML, or application-based help systems. I had a job once with the title of Documentation Specialist, but really I was a technical writer. In fact, that was a US government DOT contract, and to my knowledge, Uncle Sam knows what a documentation specialist is, but does not know what a technical writer is.


There's a very clear delineation between TW/TE and a DS because a documentation person rarely gets his or her hands dirty with content.

In reality one person has to perform all of the above tasks. If we cared, we could title ourselves as technical communicators to indicate we perform all three tasks.

I'm sure that each of us has certain tasks that we really enjoy most and excel at. Certainly though, when technical writers get together and discuss problems, innovations, and other general shop talk, they focus on TE and DS tasks.