When Is It Enough?

Recently, I thought about the ending of my own novel, The Unlikely Messenger, I wrote some time ago. As I thought about it, I said to myself maybe I don't need to publish another novel.  Maybe that's enough. 

Whether I'll follow through on this, I don't know. Either way, I'm okay. But there needs to be a point when something is enough. You may disagree. You may say why not keep going? 

If you say there's no point of enoughness, then nothing will be ever be enough. And if nothing is enough, then you'll never be satisfied. And if you're never satisfied, you'll never find what you're looking for. It'll just endless striving for more like chasing a pot of gold at the end of a rainbow. Where does that lead? Where does that end?

We could go some in so many directions with this. But since this is a technical writing blog, I'll try to keep it writing related, especially technical writing.

Creating Enough Documentation

While I believe in documenting every important procedure, function, and feature, I believe there's such a thing as over-documentation. 

If we have a plethora of documents floating around saying the same thing over and over, then we may confuse, frustrate, and overwhelm our audience. Which ones should they read? Do they need to read them all?

By creating a vast sea of documents rather than a deep pool of helpful instruction and information, we may end up drowning them with information overload rather helping them dive in to find what they're looking for. So, they may forego all our documentation or go to someone else who can help them. 

You don't combat the common problem of 

under-documentation with an overreaction of over-documentation. The key is creating documents for every piece of important information.

So how do know we created enough documentation?  

Maybe one example can help. Let's say you have the same series of products but they're just different models numbers. I don't think you need to create a document for every single model. You just have one document for that product and note the differences of the model numbers, if any, within that document. 

I'm aware if we took that to the extreme, then we would have documents as big as old phone books. I'm not advocating for such an absurdity. Even with lengths of documents, there has to be a limit of enough. So where is that? If we cover the functions and how to use the product, then this should be enough. 

Writing and Rewriting Enough Iterations

When we create documents, we have to know a point when there's enough work before it goes out to the world.

We can't sit there and write, rewrite, and edit excessively. Otherwise, we'll never get anything out the door. There needs to be a point when it's enough. So when is it that? 

Here's my take. It's neither full-proof nor comprehensive but it works:

 - We covered all the needed information on how to use the product.

- You or a SME walkthrough on using the product. (If it's a service or a procedure, then have someone review it after you're done.)

- Once you finish the document, go through it again and make any fixes or edits. (A couple times through is good but beyond that is excessive.)

- Make sure document gets reviewed before it goes out. Doing a QA on a document would count as a review.

If we've done this, then all we can do is put it out. Sometimes, you just have to publish and cross your fingers or pray that it's all good. But letting anxiety or perfection paralyzing us from writing isn't an option.

While we should strive to create quality documents, we can't expect perfection. It's unrealistic.

If customers find issues with our documents, then they'll let us know. That's the beauty of feedback. It helps us improve. We just have to move in the spirit of enoughness to get things done. When we do that and let go of perfection, we give room for our customers to help us improve documents in ways we couldn't imagine.

Not Sinking into Complacency

This may sound like I'm advocating complacency. I'm not. I'm advocating for contentment. To some, this may sound same. The difference between the two is attitude. 

Contentment is knowing you have enough and you're satisfied. You have a peace in your heart that's beyond words. Complacency is you're settling or you're comfortable at a certain level because you don't want to stretch yourself and avoid hard tasks, even if an actual need arises.

Again, we can go in many directions and levels with this. But I'm focusing on documentation. So how we know the difference?

Knowing the Needs for Documentation

To know the difference between contentment and complacency, we need to look at needs. Does a product or a procedure need a document? If so, then rise to the challenge even if it's tough. If there's already a document, then check to see if you need to revise it. If you simply don't want to, then that's complacency. 

Knowing the needs and simply addressing them helps us avoid the extremes of complacency and over-documentation.

Living with Enough Writing

If we know we've done all we needed to do and said what we needed to say, then we need to be happy with what we've written.

I like what Mark Twain said:

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

Twain knew when it's enough in a story. And we writers should do the same.

Unless there's a need, we need to be content with what we wrote. As long as we did our best, we can't live in regret. We have to be content with it. 

Pursuing Enough

Honestly, I haven't arrived at contentment completely, even with documentation. But I want to get there. So, I've been saying all this to myself too. But if I don't, what's the alternative? No thanks. I rather pursue what's enough, even with documentation.

I like what the Apostle Paul said to Timothy about enoughness:

Of course, there is great gain in godliness combined with contentment; for we brought nothing into the world, so that we can take nothing out of it; but if we have food and clothing, we will be content with these. -- 1 Timothy 6:6‭-‬8 NRSV

So, if I can fully arrive at godly contentment, then it'll be enough.