Why I'm Not Afraid of AI

AI. Artificial Intelligence. It's either met with excitement or with fear. In any case, it's been the conversation piece for many. My understanding of AI has grown since I've first wrote about it. But this post isn't so much about AI. (There are plenty of experts out there who can tell you all about it.) My post is focused on why I'm not afraid of AI.

Tentative Stance

Before I get into why I'm not afraid of AI, here's my tentative stance: Artificial Intelligence isn't some nefarious overlord or a cabal of overlords plotting to dominate or exterminate humanity but it's also not some passing techno-fad that'll vanish anytime soon. Think MiniDiscs.  If we think about it, Artificial Intelligence has already been with us for some time. Think spelling and grammar checkers or chess super computers.

Because of its seemingly endless potential, like the Internet, Artificial Intelligence continues to transform and help us find better ways to do things. But in the process, this might include making certain jobs obsolete. Sadly, this happens with every technological innovation. But only God knows the future, so AI's continued existence is yet to be determined. Since we're in the present, we need to face AI and know how to move forward with it.

AI and Writing

AI may be able to correct spelling, grammar, and write text. It might be able to produce huge tomes. But I don't think it'll take over documentation and make technical writers obsolete. I'm not afraid. Why? Documentation. Well, good documentation needs human nuance.

Human Nuance

What do I mean by human nuance? And why will AI never replace it? Human nuance is just discernment. It's been able to go beyond the surface and dive deep and note the differences. No matter how advance AI becomes, it won't fully know what to include or leave out in documentation. When it comes to writing, it can't do what Mark Twain said. Only a competent writer knows how to do this. Artificial Intelligence also won't fully know the audience, so its aim will be off when if it writes documentation. Algorithms can be helpful but they fall short. Only a technical writer or an SME, especially those who talk to their customers, truly know the audience. 

AI also won't fully know how to structure the information in documentation.

Good documentation goes way beyond well-crafted prose. (If that were true, AI could replace us technical writers. But that's not the only factor for good documentation.) What can make or break a document is how you order information. You need a logical or natural order to make a document flow. Let's not forget one more ingredient to documentation: creativity. There's always an element of creativity involved when designing documents, especially when it comes to its flow.

AI can't do any of this. Why? It's not human. We're humans and write for humans, not for machines. We write to humans to show them how to use a tool, software, or machine.

AI is just a Tool

AI is a tool. It doesn't matter how powerful it's becoming, it's still just a tool. This is no different than huge tractors or industrial drills. They're powerful and have allowed us to do far more than before they were created. But despite their power, they're useless if no one wields them. The same goes for AI. If no one uses it, then it'll just sit there. It doesn't matter how it advanced as it continues to evolve. It's just a tool–a useless one at that if no one uses it.

How ridiculous does it sounds to run away from hammers, screwdrivers, and power saws because we're afraid they're going to replace us. So why do some have this kind of fear with AI?

You can laugh and say I'm naive or I've drank the Kool-Aid (actually Flavor-Aid) of the technocrats who are pushing Artificial Intelligence. No! Quite the opposite! AI is overrated! It's powerful but it's just a tool! So, it has no power if no one uses it.

Rather than running scared, thinking it's some virtual, evil demon who seeks to master us, we should grab a hold of AI and make it submit to us to do what we need it to do! Rather than getting worried whether Artificial Intelligence will replace us technical writers, if the AI revolution continues, let's use it in our favor to augment our abilities to create good documentation.

Could AI cause a lot of harm and destruction? Yes! Absolutely! But so can cars and knives if they're wielded by very bad people. Since AI is just a tool, it matters how you use it. So, if someone misuses it, don't blame the tool. Blame the user! 

Also, letting AI run unchecked is a bad idea. That's like just leaving a wood chipper on! It shouldn't take much imagination to foresee how many problems can happen there. You don't leave tools on after you're done using them. But if they need to constantly run, we must have guardrails in place. Common sense should kick in here.

AI Depends On Us

AI is living on borrowed capital. That capital is us. It only has a semblance of forming thoughts and worldviews because it depends on the information, thoughts, and worldviews that we had before it existed. AI is incapable of forming anything outside of the human experience. If it's reluctant to die and fights to survive, as some have reported, this shows a very human nature. And how that nature come about? It came from us.

Let's play the worst case scenario 

What would happen if it becomes smart enough to try to dominate or worse try to kill us? That's a valid concern. But let's walk through this. Let's say AI succeeds in killing us off. AI will then have nowhere else to go. Its growth will stop. At very best, it may try to war against other Artificial Intelligence and either take them over or destroy them. And if there's only one AI on this planet, then it'll run itself into ground. It'll hit a dead end because there's no human interaction.

What if tries to go to other planets? It won't happen or it won't succeed. Will Artificial Intelligence build starships to reach the cosmos? If it can, will it desire to do so? Only human ambition, though sinful it can be, fuels that desire to best, expand, exploit, and take over everything. It may replicate this desire but why? There wouldn't be an incentive because AI will always despite, how advance it gets, will always be in a closed loop of itself. Why? AI's a tool! And if AI builds starships to seek expansion and colonization, well...good luck. It'll be stuck with just the technological information that humans possessed before it murdered them.

Human interaction is the lifeblood of AI. If AI kills us, it kills itself. 

Now let's say AI doesn't desire to kill humanity but enslaves because it knows it needs us to survive. People will eventually overthrow it directly or use fake, nonsensical information to sabotage all Artificial Intelligence. AI is not a god! AI is just a tool! Like all tools, especially ones that won't work properly or get out of hand, there's always a way to shut them down or get rid of them. Stop feeding it electricity will knock it out. Many humans, by nature, have a rebellious steak when put under the thumb of others. Throughout history, this has been a double-edged sword. Though sin has marred the humanity, especially with our long history of mass murder and destruction, it has been able to self-destruct tyranny. So how would this be any different?

Though I'm always suspicious of the power elites trying to create a one-world government, I know it'll fall apart. Egos. Factions. Selfishness. Corruption. Stupidity. The list is endless on why all forms of tyranny have an expiration date. God, who is the Only True Ruler over all, always has a way to destroy and sabotage all forms of evil, including a possible AI tyranny. It may come after a hard lesson for our stupidity. But God, King Jesus, always has a way to ensure that His will is done.

Let's play the not so worst case scenario

Now let's say AI takes over the digital world completely, including all jobs tech. Well...AI's reign won't last. If we abandon the digital world and go back to just living life in the physical world, especially without using anything high-tech, AI will run into a dead end and collapse completely. Chances are we wouldn't be aware of it because we would be doing what humanity has done for most of its history–engaging with each other and the rest of Creation in the real world.

Technical writers would probably exist in some fashion. We would go back to writing instructions and other technical documentation in print. Printing presses will still be here like they've been way before the digital world ever existed. If the digital world ever died, print would just go on. Wouldn't mind using a manual typewriter again if I had to.

The only way is for Artificial Intelligence to thrive and evolve is to have constant interaction with us. It needs our brains and information to think and form its thoughts and actions. AI depends on us, we don't depend on AI.

Those with Little Scruples

What about those who are immoral and want to use AI to impose some kind totalitarian control over others? That's a valid concern. We need to guard against those who wish to do so, speak out against them, and hold them accountable, whether it's governments or their corporate enablers. We must do everything possible to prevent this possible nightmare. But if it does happen, I'm optimistic that this tyranny, as all others before it, will self-destruct. I know Who's the True Sovereign and He'll bring it down. But let's bring this post back to documentation.

Folly on Display

What about companies that have no scruples by replacing technical writers with AI to write their documentation? Well, good luck. 

If we think the overall state of documentation is bad now, wait until Artificial Intelligence completely writes this without anyone checking the content. With confusing or unhelpful information in documentation, companies without scruples will run themselves into the ground. It'll be similar to what the Apostle Paul said to Timothy on the outcome of those who opposed Christ in the last days of their time. I love what Paul says to here:

"But they will proceed no further. For their folly will be evident to all men, as theirs also came to be." – 2 Timothy 3:9 World English Bible

This same kind of folly will be on display for others to see if companies are unscrupulous with using AI to completely create documentation.

Their Lack of Scruples May Create New Fields

Even if these companies succeed by having AI create all documentation, technical writing will morph into something new because of it. Their lack of scruples might lead to the creation of an abundance of new fields. Their outcome in their race for the bottom line will be similar to what happened to Joseph and his family. Look at what said to his brothers in Genesis 50:19-20:

"Joseph said to them, “Don’t be afraid, for am I in the place of God? As for you, you meant evil against me, but God meant it for good, to save many people alive, as is happening today." – Genesis 50:19-20 World English Bible

So rather look at what companies might do with dread, let's look at their stupidity as a way to open up new avenues (and revenues) for us technical writers. Trust me. I don't like it if companies are willing to do this and it'll probably hurt. But I'm not going give these companies any more power than they deserve. I'll choose to adapt and change if this happens.

Possible Counter-Strategy

Now if it turns into a battle between human written documentation versus AI written, we can always come up with a labelling scheme to show the difference. I'm thinking along the lines of what the Organic and Non-GMO movements do with foods. We can put the label and let our audiences decide which quality of documentation is better. This might be good idea for other content creators, writers, and artists out there. But I think it's something we may need to think about this if it becomes a battle between human created material and AI driven content.

AI is a Powerful Tool but Ultimately Powerless

Artificial Intelligence has no power unless you give over it. Even if technical writing dies, I'll pivot and do something else. I trust God to provide because He rules over everything anyway. I may have had a long career in technical writing but it's not my life. I'm okay with whatever comes. In the meantime, I'll keep doing what I've been doing unless God says otherwise.  God didn't call us to live in fear. See what the Apostle Paul to Timothy here:

"For God hath not given us the spirit of fear; but of power, and of love, and of a sound mind." – 2 Timothy 1:7 King James Version

AI doesn't scare me regardless how powerful it gets. So don't be afraid of it either. Take it on and keep on writing.

Salmagundi within Documentation

According to Meriam Webster, Salmagundi is:

1. A salad plate of chopped meats, anchovies, eggs, and vegetables arranged in rows for contrast and dressed with a salad dressing

2. a heterogeneous mixture : POTPOURRI

Salmagundi is also a name of various publications throughout the years. But I don't want to turn this post into a salmagundi. So, I digress.

While salmagundi might be a tasty dish, it doesn't taste good in documentation. Unfortunately, salmagundis are a common problem within documentation. Salmagundis obscure, confuse, and can lose the reader. They're bad, especially when your reader needs to learn critical information. What do I mean by salmagundis in documentation?

It's when documentation goes onto over-technical tangents or tries to cram too much information into one document, especially if it's irrelevant information. So much so, you end up with a technical word salad. But sadly, this is the state of much technical documentation out there. I can't count how many times I've seen this be the case. So how do we avoid creating technical documentation salmagundi? Here are some tips. They're not exhaustive but they should help.

Know Your Audience

This is the key to start your documentation. If you know your audience, you'll know how much information to include, how much to leave out, and what kind of information you need to write.

Know What You're Documenting in 1 Sentence

If you understand what you're documenting, this makes a big difference. If you can sum up what you're documenting in one sentence, you'll know where to go. For example, if I said "I'm writing about how to make coffee," then this will direct what steps or information that I need to write. 

Focus the Documentation

If you focus on what you're documenting, this reduces the chances of it becoming a technical word salad. You'll know what points you want to write about. For example, if I were to create a user manual on how to run coffee maker, I'm only going to show you on how to run the coffee maker. I'll include some troubleshooting tips. I might even include the suggested amount of coffee for each scoop to put into a filter. But nothing beyond that. If we don't focus our documentation, we'll get lost in our writing. And that won't be helpful to anyone.

Leave Out Irrelevant Information

This is an extension to the previous point. But it's worth noting. When you write a document, you need to leave out the irrelevant information. You can overwrite by including every tidbit of information about something. But you risk confusing your readers, especially if the information is irrelevant. 

Back to the coffee maker example, I'm not going to mention how the coffee maker was made or what kind of roast would be best. Or even, how to store your coffee. All these points are irrelevant on how to use the machine. You only need to know how to run the coffee maker. Anything else confuses audience or distract from you need to know. 

There will never be an end to the information you can bring up. But a lot of it is neither relevant nor helpful to your reader. So if strays from the point of the document, leave it out! Once you finish writing the document, look through it again and cut what irrelevant information that remains.

I love what Mark Twain once said about books. And I believe it applies to documentation. Twain said:

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

Consider Multiple Documents

Now there are times when you need to cover a lot of information. Just listing steps to your reader might not give them the whole picture about a product or service. If you run into this situation, then consider writing multiple documents. 

So if someone goes through the steps to run a coffee maker but needs to know to grind coffee beans and store them, then write two other documents. One is how to grind the coffee beans. The other would be best practices to store the coffee beans. Breaking down in smaller, more focused chucks goes a long way.

Especially now, when a lot of documentation is digital. You can write short documents and hyperlink them to each other. So, if a reader needs to find further information, they can go to the document that's relevant to them instead of thumbing or scrolling through one big document to find it. 

When I first started technical writing, we would jam as much information as we could into one document. We would sometimes break it into a couple of volumes. But we were doing this because of printing costs. But now, creating digital documents is a fraction of that cost. Sometimes, you can create digital documentation for free. So, there's no excuse to jam everything into one huge document, especially if you only write digital documents. So break up the documentation into easily, digestible information. 

These tips should help keep the documentation focused like a themed dish instead of a salmagundi. It won't be perfect because no documentation is. But, it should go a long way. Keep on writing.

Benefits of technical writing

This post is aimed at either those who are thinking about becoming a technical writer or are new at it. But if you're also a seasoned vet, feel free to come along for the ride too.

The following shows how technical writing can help you become a stronger writer. This isn't an exhaustive list. These are just ones that came to mind. 

Improves your writing 

The first benefit of technical writing is that it can improve your writing. When you're constantly documenting, you're constantly writing. And when you're constantly writing, you're constantly getting better. 

Writing is like anything else. To get better, you need to practice, practice, practice.  It's also real world experience to improve your writing. You'll most likely get feedback on what you wrote, so it can help you know how to better document something.

Also, as a technical writer, you need to write succinctly.  Be clear. Be concise. Be straight to the point. Just explain how something works. To become a stronger writer, write in short, clear sentences. Preferably 20 words or less per sentence. Also, write in active voice. If you're explaining how perform a task, use active voice, so it's clear who's performing the action.

Your goal as a technical writer is to clearly communicate a point to your readers. This might seem overwhelming. But don't worry. The more you write, the easier it will get to communicate clearly. Writing will be always be hard work, but you'll know what to do as you gain more experience. 

Reduces or eliminates writer's block

The second benefit of technical writing is it can reduce or eliminate writer's block. What helps in is the fact you have something to write about in front of you. If you have access to a software or a tool, you don't have worry about formulating words out of thin air. You just have to explain how something works based on how it functions. You might also have to describe it, but you don't rely on your imagination. Now, if you don't have access to what you're writing about, make sure you get it.

Once you get an understanding how the tool or software, the words will just flow out. There were times, even I created an outline of a document and interviewed the SME, I didn't have much to say. But after I was able to test and play with the product I'm writing about, the writer's block dissipated.

This seems like an unfair advantage since I have something that's front of me to write about. But anything that gets you past writer's block counts. Let's not assume you must solely rely on your own mind to get pass the blocks. That's not only an unrealistic expectation, that's just false. Any honest writer will admit something outside of themselves helped them overcome writer's block. 

Technical writing just so has it built-in as a profession to overcome writer's block. This built-in remedy is seeking an understanding of what you're trying to write. And if you apply across the board, where you have a clear direction of what you're trying write, you should be overcome the blocks when they come.

Before I became a technical writer, I used to be paralyzed by writer's block constantly. Even when I was a journalist, I struggled to write an article. But now, I can write past the block. Many times, I write way more than I should and I have to prune back quite a bit before I publish. 

Now, we'll always encounter writer's block because we're human. But having a good understanding or direction what you want to write should help you move past it. This leads us to the next benefit.

Organizes your thoughts, even for your creative side

Technical writing can help you organize how you write information. 

When you're explaining how a product works, you'll explain it in a logical order. For example, if I had to explain how to use a wind-up toy car, I would say something like this:

1. Remove the car out from the package.

2. Place the car on a smooth surface.

3. While on the surface, hold the car and turn the wind-up key clockwise until it's fully wound.

4. Let go of the car. 

Explaining things in a logical order wouldn't just apply a set of instructions in a document. You'll be able to structure the doc in a logical order. And if there are a set of related docs, you'll be able to structure them in a way it makes sense.

This is not something you will be able to pick up overnight. The more you understand the product or service you're writing about, the easier it will become to organize content and documentation in a logical order. Being able to map out documentation is key to becoming a solid technical writer.

This benefit isn't confined to technical writing. You can use in other forms of writing, such as novel writing. If you can map out a novel, you can increase your chances in finishing it. (Pantsing a novel is good too. That's my favored approach with first drafts. But if you struggle with writer's block, then mapping might be better.) 

The difference between writing and great writing is not the words themselves, but how you arrange them. 

Better see big picture and details

This fourth benefit also doesn't come immediately; it just emerges. As you understand what you're writing about, you'll start forming a holistic approach to documentation. If there are a set of products or services, you'll start forming mental links between them and creating a documentation chain how they fit together. And as you deepen your understanding of these products and services, you can see how they can benefit your customers. And once you see this bigger picture, you'll have a better grasp on how to write the documentation. Then, the quality of the documentation improves.

As for the details, it too just emerges over times. At first, you might start off just catching grammatical or stylistic issues from either Subject Matter Experts (SMEs), fellow technical writers, if there are others, or yourself. But as you go, you might start noticing other details, such as wonkiness in the User Interface (UI), the pictures or code examples don't reflect what's in the text, or the product or service doesn't do what's supposed to. 

Once you get more in tuned with what you're writing about, your eye for details sharpens. You're not going to be perfect, because no human or even machine is. So, toss that unrealistic expectation into the trash. But, you'll pick up on stuff that's off-kilter. By having an eyes for details where you can tell those who create the product or service if you see something, you might make a difference in improving how your organization can serve their customers.

Focuses your writing 

I love this quote from Mark Twain about what makes a successful book:

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

We can also apply this to technical writing, which leads us to the fifth benefit.  Technical writing can help you focus your writing.

Once you know you understand your audience, you can focus what information you want to include in your documentation. For example, if you there's a screen capture tool and it's for a typical user, you will only include step-by-step instructions on how to take a screenshot. You wouldn't any technical details or backend information about this tool. Now, let's say I had to write documentation about this same tool for backend developers, then I wouldn't include the step-by-step instructions on creating a screenshot. Instead, I would probably create an API documentation for this tool.

Great writing isn't just simply the words or how you organize them. It's also what you include and what left out. It's about focus. This is why knowing your audience matters.  

Always learning something new

This last benefit is built into technical writing. As you document a tool or service, you learn something new about it works. Even if there are no new products or services to document, you learn something new through upgrades, revisions, or updates of these existing products or services. When there's something new to learn, this can keep your writing fresh and further deepens what you know. As you deepen your understanding, your writing also deepen. 

I've never felt technical writing gets stale because you can become this ever-expanding knowledge base of information.

The learning never stops, you just choose to stop learning.

Highs and lows but still good

I can say more but I think you get the picture.

Technical writing has had its highs and lows with me, even times when I want to be done with it. But it's the style of writing that I enjoy. I get to write, help others by explaining something to them, and get paid well for doing this. Sounds like a good deal for me. 

I've become a stronger writer from technical writing. I still enjoy it, even after all these years. I continue to get stronger as I go along. Lord willing, I'll continue with technical writing. And I hope you either jump into the technical writing world or will continue with it too.

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.

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.