Writing for Validation? No!

There are many reasons to write. But there are reasons not to write. Validation is one.

If you're writing to seek approval, then you're going to be disappointed. While it's crucial for writers, especially those of us who are technical writers, to build bridges with the audience you're trying to reach, you're not going to find validation from them. 

The audience doesn't care who you are or what you write. Ultimately, they're just looking for information and content they want and they move on once they get it. If they return, it's because they're looking for what they want, not you. Now, some may counter me and say they like certain writers. Is it the writers themselves they seek, unless you're some nut job stalker, or stuff they write? You know the answer to this question.

If you're looking for approval with your company, good luck with that too. You might get some unsolicited advice if you're constantly asking Subject Matter Experts (SMEs) whether your writing is any good or your documentation has any value. They'll let you know if they're not happy.

Taking constructive criticism is one thing. We need it to improve as writers. Writing is an ongoing process. We only get better by doing it constantly and humbly taking feedback. Heck! You can even send surveys to your audience and the SMEs to see how you can improve documentation. After all, documentation is about serving your audience. But seeking validation is another. It's an unhealthy extreme. Validation is a phantom prison!

You're afraid of what others think and you ruminate about the possible criticism or some half-cocked comment from someone. So, you try to appease them and you lose your voice in the process. But in reality, they're not even thinking about you at all.

The fatal problem with seeking validation is it makes you the center of the universe.  But guess what, you're not the center. 

Seeking validation is in the same vein as comparing yourself to others, but it takes it a step further into narcissism. What one really wants is accolades and praise? What someone who seeks validation wants is an echo chamber. Let's be honest. Do any of us go around seeking to find criticism, even if it's constructive? No! We prefer to do things our way. I'm not saying that's right. I'm just saying that's what we tend to do.

So why seek validation for your existence as a writer, particularly a technical writer. Let's keep our heads down and power through to great documentation. Leave the rest up to God. Seeking validation is a big waste of time and energy. Don't do it! Be humble yet confident in your abilities. But if you're writing only because you want the approval of others and want people to extol you, then maybe you shouldn't write at all.

Technical Writing: Systematic Advantage

When my wife and I watch campy movies, there's a typical theme of a writer who has writer's block. The writers in these movies try to write something but can't. Or when they start writing on the computer, they let out a sigh, deleting everything till it's a blank screen. While these scenarios are exaggerated, there is some truth to it.

It's difficult when you must create something that relies on your mind. I know. I've written a novel before. Writer's block is always lurking around the corner. When you write, that constant inner critic is always trying to lead you to that corner. Those who are career authors, I don't envy them. God bless them for keeping their imagination going, though they struggle to craft meaningful words on the pictures they're trying to paint.

We technical writers have a systematic advantage over our creative counterparts because we document things based on what we can see and use. (I mean systematic, not systemic because while the writing process is universal, we're in a different category than creative writing. I suppose you could say we have a systemic advantage. In any case, we have an advantage.) If you're documenting user interfaces, we can walk through each step of the way to help us write. So the chances of writer's block decrease, though it can still happen.

Should we feel ashamed that we do have this over other writers? Absolutely not! But we should be thankful that we don't have those blocks. Of course, our blockers are from SMEs, developers, or whatever. We can't write anything until they're removed. But once we remove these blockers, we are to free to write till we're done. Our blockers are external not internal, so we have an advantage. So let's use it to create great documentation. Since we don't suffer writer's block like the creatives, there's no excuse for sloppy documents. Am I saying perfection? No! There's no such thing as perfect documentation. But we can strive towards excellence.

So, my hat goes off to you creatives for doing what you do. Keep writing! Thank you for building those worlds for us to enjoy and think about.

 

When you Doc as Code

What is doc as code? Doc as code is basically two things. One, it's creating documentation with the same tools as you would use to create code. Two, it's using similar methods of creating, versioning, and publishing documentation as you would with code. 

What do I think about this? Short answer is context. If you're creating or editing material in a software environment that uses Agile methodology, then you should doc as code. Otherwise, I wouldn't worry about it. If you're in this context, I'll give you a few,  brief reasons why you should doc as code.

Save Costs

The first and foremost why you should doc as code is to save costs. Tools, licensing, even training on how to use tools all cost money. It also costs time to maintain and invest on different tool sets. If you're using the same tool to create code and documentation, you can save on both. No further explanation needed. 

Easier to Build Bridges

If you're using the same tool as your Subject Matter Expert (SME), it's easier to build bridges to create documentation. If you're using the same tool(s), it's easier to collaborate together on documentation. This doesn't mean you have to learn to code. (But it might help to know a little bit.) In some ways, using the same tools and releasing documentation the same way as code is like you're speaking the same language as your SME.

More Unified Experience

If you doc as code, then the release of software and documentation is much easier. The obstacle of getting your documentation in a certain format, so it goes with the software release is no longer an issue. You just have to make sure you and your SMEs are working in sync to make sure the documentation reflect what's in the code and vice versa. And that can be challenge in itself, so why would have other unnecessary issues to prevent this from happening.

To find out more about doc as code, check out these resources:

https://www.writethedocs.org/guide/docs-as-code/

https://www.gitbook.com/blog/what-is-docs-as-code

https://github.com/readme/guides/code-as-documentation

When you don't have all the pieces

When you create documentation, there are three fundamental questions you need to ask.

1. What is the thing you're trying to document?

2. What kind of document are you writing?

3. Who is the audience for this document?

If you get answers to these questions and find the key Subject Matter Experts (SMEs), you're on your way to creating good documentation. But let's be honest with ourselves, even with this information, there's a good chance that you'll still have missing pieces. What do you do then? 

If you're in a circumstance, where you can test the product, say software or API calls, then you can probably fill some of the missing information. But not all technical writing circumstances are the same. Sometimes, we're detached from the subject we're writing about because we're not able to test a product. Going on a limb here, say nuclear technology. It doesn't have to be this extreme. But it could be just simply no way of testing out your subject or product. So what do you then?

One thing you can do is be persistent. As you talk to the SMEs, ask your questions along the lines of the fundamental questions you've asked initially. When SMEs are stumped from your questions, you can ask them who would know. They might direct you to another point of contact or get back to you if they need to dig into this. In any case, finding the missing information for a documentation isn't impossible. It just requires persistent. 

The worst that can happen with documentation, is that you can't write it, because the information doesn't exist and maybe the subject just a concept for now. And that's a planning issue beyond the scope of your responsibilities. Aside from this, if you're persistent you can find the missing information.

It reminds of the game Chrono Trigger with mysterious gray chests scattered throughout in different places and time. When you try open them, it would play a song and a dialog box tells you a mysterious force is keeping it locked. You can still play the game but it seems like something's missing when you can't open these chests. These chests stay locked until you charge up Marle's perdant and that's when you can open these mysterious chests.  

Like the way you need to charge up Marle's pendant to unlock these chests, you just need to find that piece of information or point of contact that help links the missing pieces together. Creating documents can be an interesting quest.

Be thorough, not Pedantic

As technical writers, we must be thorough when we create or edit documentation. If we're not, then we might present shoddy, confusing, murky, or incomplete information to our audience. But being thorough doesn't mean you should be pedantic. 

Pedantism is annoying at best and destroys relationships at worst. It's unnecessary, short sided, and stupid.

But what's the difference between being thorough versus being pedantic? For us, being thorough is carefully making sure the documentation is clear and helpful for our audience. Or when you're dealing with SMEs, you ask good or the right questions to get the information you need. But being pedantic is pointing out, or if we're being honest with ourselves, picking on small details that don't matter. 

Does it compromise the clarity of the documentation? If not, let it go. But if one wants to insist these details are important to point out, then think carefully and honestly. Are they important? Seriously, are they?

Or, if there's a small error or limitation and you can safely assume (it's okay to assume sometimes) most people are going to figure it out, then let it go. 

How about speaking with others? Are you going to point out to small inaccuracies in their word choices because it's not to your liking?

One of the worse forms of pedantism to me is when someone corrects someone's grammar or pronouncing when they speak. Why?!  Did they ask for help speaking? What are you doing other than showing how smart you are and showing how stupid you think someone is? Are you that thin skinned that you can't possibly hear an imperfection? If you understand someone's point clearly, then why do that. All it does is sour relationships. If you want to be a successful technical writer, it goes beyond great writing, grammar, and editing skills. It's also about building great relationships. Without it, you might have nothing to document.

Don't think I'm okay with bad grammar. I just save correcting and improving the grammar for documentation. And even then, the grammar rules we uphold aren't as ironclad as you think. (While these rules give structure and meaning to any language, they aren't infallible. Sometimes, these grammar rules are fake.) Don't believe me. Look it up. 

If given the choice, I rather take a clear sentence that they may not be perfect grammatically, than one that's "grammatically" correct yet clunky in its explanation.

Guess what? No matter what you do, no documentation is perfect. No tool is perfect. No one is perfect. Nothing except for God is perfect. It's an exercise in futility if you strive for that. Instead, strive for clarity, technical accuracy, and good document design the best you can. The rest will take care of itself. If you need to make improvements, then so be it. 

Besides, you wouldn't want perfection because there would no longer be any innovation, whether on the subject you're documenting or documentation itself. Think where that ends up, if there's nothing to improve because of perfection.

Pedantics, like legalists, focus on the minute details but not the big picture. It reminds me what Jesus said when He rightly rebuked the Pharisees for their pedantry. Check it out.  

Also, pedantics may like to impart their "wisdom" on others. But they don't like when someone else does it to them. If a pedantic person is honest, then they don't like that. It reminds me of what Jesus said here about the measure in judging people. Check out what He says here. If anyone wants to be pedantic, then they'd better be prepared for other pedantics to correct them. 

If not, why carry the weight of pedantism around? It's not just a burden others, it's also a burden on yourself. Dump pedantism into the metaphorical ocean. (Don't actually dump anything into the ocean. Seriously. Don't. Let's keep it clean, if we can.) Free yourself from it. If you don't, it can hinder you from growing as a technical writer.

Now, it would be hypocritical of me to lance pedantism from a high holy horse without admitting my own faults. I've been guilty of having some pedantic tendencies in the past. Mine was trying to absolutely uphold style guide conventions, but I didn't take context into account.  While I still think style guide rules and convention are great, they're not absolute. I'll also still uphold style guide conventions, but if a sentence sounds clearer and more natural and it "breaks" with convention, then I will choose this sentence over some arbitrary rule. My focus is on the big picture: Creating clear and helpful documentation for the intended audience.

By trying to get away from these tendencies, it's helping me to continue to grow as a technical writer. I'm able to work with liberty and confidence. And my relationships with SMEs have also improved over the years.

Life is too short to be pedantic. Focus on the big picture. Is the documentation clear? Is it helpful?  Writing in active voice goes a long way with this. Is it for the intended audience? Building genuine and good relationships with SMEs will help you understand your audience. Do it with a smile and laugh.

Don't let the minutest of details distract you from that, especially the ones that don't matter in the big picture. When it comes to pedantism, that adage "the devil is in the details" applies. So, let's prevent the devilish details from winning out.

Be thorough, not pedantic.

Technical Writing Isn't Boring

I once saw a movie where an editor insulted a writer over her manuscript for a book and said she needed to write user manuals. I was incensed when I saw that and jeered at the editor. (Maybe I'm exaggerating but I did say "excuse me?" at the character.) 

It's funny because that actually happened to me in a previous writing life as a journalist, where an editor told me that I was better off as a technical writer.

Whether it's in movies or in real life, there seems to be a sentiment that technical writing is boring. It's sleepy. It's dull. It's lifeless. Really?! 

How's it boring when you get a chance to always learn something new, whether it's entirely new product or an update? How's it boring when you can get a chance to write for different industries or subjects? One of the benefits of technical writing is you can always expand your knowledge base.  Boring is if your mind is stagnant.

How's it boring that you get help people through your writing? You can get a sense of fulfillment knowing that you helped someone accomplish a new task. 

If you write documentation just right, it can be like one of those videogame walkthroughs. The genius of a walkthrough is that you get to go on a journey through the videogame and the purpose is that you help someone through the game. It's the same with documentation, just without the commentary or shouting. Taking someone on a journey explaining a product or service might be draining but not boring. Boring is just remaining on Step 1. Technical writing takes steps 1,2,3, and beyond till the end.

How's it boring when you can meet different Subject Matter Experts (SMEs) to help you get the technical information you need to write the documentation? Boring is when you completely rely on own imagination, thoughts, and view. Your writing can get pretty stale, pretty fast, so it becomes boring. 

I met SMEs from across the globe and from all walks of life. Their takes on things and their knowledge has always helped me. The documentation usually turns out better than I could imagine, even if I couldn't see it at the time I was creating a document. Why? Collaboration is what can give technical writing life. 

And if you write in active voice and clear and concise prose, it's anything but lifeless. Passive voice and verbose sentences are the bane of technical writing. They not only confuse and muddle but are lethargic and vapid. So we need inject the syntax with active, concise language to bring life to documentation. 

Clear information isn't boring. Boring is stuffy text, pontificating or rambling on to whatever it was about. And you get lost what we're reading, or in my case, you just fall asleep.

Writing documentation like a flowing river won't put your reader or you to sleep like a meandering creek might. 

Well, maybe a white paper on some theoretical concepts might put me sleep. But for others this keeps them up all night. You can have white papers that are engaging reads.

Technical writing can be hard, frustrating, draining. Boring? Don't think so.

Ask Two Questions, Maybe Three

When you create a document, you need to ask two, maybe three questions. But at least, you need to ask two. So what these questions? They are:

- What is this thing I'm writing about?

- Who is the audience I'm writing for?

- What kind of document am I writing?

Why does it seem I waffle between two or three initial questions? Well, you may not need to ask the third question because it may come up naturally in your conversations with the SME(s).  Only ask the last question if you need to. Otherwise, the SME(s) may lose confidence in your ability as a technical writer.

But the first two questions, you should definitely ask when creating documents, especially if you're in a new setting. So why these two questions? Well, these two questions will help set the direction of your documentation. 

If you know what you're writing about and who you're writing for, it'll help you know what kind information to write in your document. Let's say you're writing a user guide on how to use a software for storing recipes and your audience are home cooks and chefs, you're not going explain the technical inner workings of the application. You're just going to show them step-by-step how to enter and save their recipes. That's it. 

When we approach documentation, we should take Mark Twain's advice when writing good stories. He said:

"A successful book is not made of what is in it, but what is left out of it."

So, let's focus on what to write and chisel out the rest. Our audience deserves it.