Don't dare to compare

Whatever you do, don't compare to yourself to others as a technical writers. It doesn't matter whether you're trying to see if you're better or if you believe that you don't measure up to others, just don't do it. It will imprison you mentally and might affect your writing. Not to mention this is a waste of your time and energy.

There was a point in my career where I felt like a phony or a horrible technical writer because I don't have a BA. Due to some circumstances in my life, I couldn't go further in my higher education. So I settled for an AA, which I got after I became a technical writer.

When I saw other technical writers with a BA or MA, I felt very inadequate. This would get reinforced when I tried for other technical writing jobs but couldn't get them. It got worse when I saw other writers and focused on how they could write far better than me. And to top of it off, I would have some engineers who challenge me on grammar and style. I felt hopeless.

I would go to my office with my head down and would crouch in fear of engineers and others. My voice got shaky and uncertain. I was a mess for a while all because of these supposed points against me. Many times, I considered giving up not just technical writing, but writing all together.

Things were bleak until this Scripture verse came to my mind.

We do not dare to classify or compare ourselves with some who commend themselves. When they measure themselves by themselves and compare themselves with themselves, they are not wise. -- 2 Corinthians 10:12 NIV

As I kept thinking about this passage, I realized what I was by comparing to others was stupid and a waste of my time and energy. I realized I was my worst enemy. Other writers may write better than me. But so what? That's fine. Good for them. I'm not them and they are not me. And why was I assuming they are better? It could be their writing is just different. And that's good. It would be a very boring world if we all wrote the same way.

Writing is a thought process and we all think differently. The truth from this piece of Scripture started to break some light through the dark cloud over me. But the cloud was still there.

The next thing that made this dark cloud thin out was a book called Grammar Snobs Are Great Big Meanies by June Casagrande. This book was freeing for me. It showed that grammar and style are not always clear cut. Thanks June for writing such a much-needed book for us writers!

So whenever an engineer tried to challenge my editorial decisions, I wasn't threatened anymore. I would thank them for their feedback. I would change things if they were right or just simply better. If they were plain wrong or unnecessarily dogmatic, I would show them gently why I chose a certain way of saying things.

I may be a writer and know some principles of good grammar and style, but I don't know everything about it. I've even been wrong on things. Guess what? That's okay with me. As a writer, especially a technical writer, you have to be willing to learn and be humble about things.

The dark cloud was thin but still there. The last stronghold of my inferiority complex was my lack of a higher degree. It didn't lose its grip until others helped me see that my premise was faulty and nonsensical.

The dark cloud over me dissipated. I was free to pursue this simple adage: If you want to be a writer, then write.

A degree doesn't make a writer. It's what they write that makes them a writer. You can't trade experience for a piece of paper that says you're well-educated. In my humble opinion, real-world experience is more valuable than a degree.

Now for those of you who have BAs and MAs, God bless you. No one can take away the hard work and perseverance you put into getting that degree.

I have no regrets except one: the amount of days, weeks, months, and years I spent beating myself.

Technical Writer, a misnomer

Here goes my rant about technical writing:

What is a technical writer? A writer who writes about technical things? I guess. I don't know. It seems that what considered technical writing is a complete misnomer. Why do I say this? It seems based on the many years of experience I have, I do very little original writing. At very best, it seems I can get write in the holes to make up for missing content. Most of the time, it just seems I am spending designing documents, proofreading, editing or rewriting muddied content.

Maybe I'm being picky but when I think about technical writing, it should be about writing technical content from scratch. This should be done by research, or interviewing SME, or both. But the fact that most of time, I don't get to write original content most of the time really calls into question the moniker known as "technical writer."

And if you want to write original technical content, then you need to be a programmer or an engineer. If that's the case, then these SME should write, revise, edit, design, and publish their documents themselves. Other than proofreading, rewriting the content, if needed, and designing the document, what do they need us for?

I wonder half the time, if I'm an actually a writer or a technical typist with style (now, there's a job title). But at the end of the day, it doesn't matter. I get paid to do what I do, when I do it.

I'm not being a crybaby for not writing original content most of the time. I don't mind doing what I do. I actually enjoy it. I'm merely calling in question the label "technical writer."

Maybe other terms like "content auditor" or "technical rewriter" would be better terms. I would be fine with using terms that exists already like "document designer", "technical editor," or "documentation specialists". I think these are better terms to describe to what we do, but the term technical writer, I dunno.

Maybe you're experience is different than mine. If you have written original technical content, then great. I have written ghostwritten original tech content as well. But to most, it wouldn't be considered technical writing. I'm just saying, unless you're writing original technical content, I think it's time to rethink this job label: technical writer.

Without a shadow of a doubt

If you put out technical documentation you're unsure of, then there's a big problem. Chances are if you're not certain of some content in a document, then your audience may be uncertain too.

Unless you're dealing with theories or scientific findings in white papers, technical documentation must be a rock of certainty to the user. Why? It's because you're guiding your audience to do something. If you're not instructing them, then you're guiding them along to explain some information. In either case, you shouldn't fly blind on what you're writing or editing before you publish.

So how can you make sure you understand what you're writing?

Big picture

Understanding the big picture of a product or service of what you're about to document is extremely important. If you don't have an idea of what you're writing about, it will show. 

If you sit down with an SME, have them tell you briefly what something is. Once you get a gist of what you're writing, the rest is just taking the next steps. Don't get hung up on details. Those will follow as you move along. It's more important to take a step back to see the bigger picture, so you know how to create a document. 

Understand your audience

It's important to understand so you would know who are you are writing for. What kind of information will you include? What information not include? For example, if you're writing for a software company that helps electrical engineers create schematics of an electric circuit, you should find out what schematics and electrical circuits are before you proceed. However, you wouldn't explain what these things are to an electric engineer since they should know. You simply explain to them how to use the software. 

For more about knowing your audience, please check out what I said previously.

Ask Questions

If you're unclear on what you do, please ask questions. Ask and never assume. No one should expect a technical writer to be an SME. Do as much as research you can on your end. Then, ask the SME questions about the product or service you're uncertain about. Any SME worth their salt will be able to answer your questions. Don't be afraid to ask. It's better to ask plenty of questions and put out an accurate and clear document, than to put out a document that's unclear, inaccurate, and full of uncertainties.