Two Nights, One Tutorial: The Hard Work Behind Sharing Knowledge

Yesterday's article surprised me.

I wrote a nearly 4,000-word guide on using Claude Code in China. After publishing, the view count wasn't impressive—barely 2,000.

But the share count exploded. Nearly 200 shares and climbing. This might be my highest share rate ever.

It confirms something: people love practical content.

When we see a hands-on tutorial, our first instinct is to save it or share it with a friend. Whether we'll use it immediately doesn't matter—"storing it away" feels valuable.

Honestly, seeing all those shares made me happy. Writing tutorials is genuinely exhausting work.

1. Writing Tutorials Is Hard

Friends who know me well know I prefer sharing reflections.

I actually resist writing tutorials. You have to extract tacit knowledge from your brain and break it down into explicit steps:

• Is this screenshot necessary?


• Can a beginner follow this logic?


• Need to verify if the process has changed.

That article took over two hours. I just wanted to lie flat when done.

So why write it?

Partly because I promised a friend (and my wife kept nudging me to honor that promise). But mostly, I genuinely wanted to share Claude Code.

But today, I want to talk less about the tutorial itself and more about a reflection on "how to learn."

2. Keywords > Tutorials

I don't know how many of those 200+ sharers actually followed the tutorial step by step.

Actually, it doesn't matter.

For readers, I think the greatest value of my articles isn't those thousands of words of steps—it's that you gain a "keyword."

Like Claude Code. Like CodeParty.

I strongly believe: in the AI era, knowing "what exists" matters more than knowing "how to do it."

Through my article, you learn about a tool called Claude Code that can change how you program. That's enough.

As for specific installation and configuration—my guide might not be the best. Take that keyword, search for it, ask DeepSeek or ChatGPT:

"What is Claude Code? How can I use it?"

AI can explain it more clearly and give you even more detailed steps.

I do the same when browsing Twitter or GitHub. I rarely follow others' tutorials step by step. I'm scanning for keywords. Once I spot something valuable, I grab that word and figure it out my own way (usually by asking AI).

Tutorials are just guides. Keywords are the keys.

3. Why Do I Still Write?

Since everyone can ask AI, why did I bother writing those 4,000 words?

Because of validation.

Tool experience can be "distorted." Feeling great when first starting doesn't mean it's actually great. When I first started, I was excited and wanted to share, but I didn't—my emotions were clearly skewed from objective reality, and my understanding had gaps.

I used Claude Code for over a month. I developed the SlideNote browser extension with it. I rewrote the inBox Notes PC version. I stumbled through pitfalls and actually built things with it. Only then did I feel comfortable throwing this "keyword" out to you.

I don't want people to waste time.

That's why I honestly discourage beginners at the start: if you're new, Claude Code has a learning curve. Try Trae first.

4. Final Thoughts

Writing tutorials is tiring. The numbers might not look impressive. But seeing so many shares proves it has value.

If I find better tools or discover better "keywords" in the future, I'll probably keep writing detailed tutorials while complaining "this is too exhausting."

After all, actively seeking and sharing—that's the joy itself.

Hope everyone finds their own new continent through these keywords.

By Gudong, indie hacker building inBox Notes. I write about AI-assisted development and the indie journey. Find me on GitHub or X/Twitter.