Quite long before the Publish0xTutorials contest was announced I'd already written a tutorial on how to write a Publish0x article. Of course, that tutorial was a joke and I'm not going to present it to the contest. Instead, I decided to create a new, more serious article on the topic.

I must confess that I myself don't always follow all the below points. Sometimes I'm too lazy to do the whole homework, sometimes I don't have enough time, sometimes my writing simply doesn't worth all those efforts. However, I do believe in what I will put down below.

That being said, let me begin my article, or a meta-tutorial, on

How to Write a Good Publish0x Tutorial

And, after all, it's not so very difficult a matter to compose an article of the genuine Blackwood stamp, if one only goes properly about it.

Edgar Allan Poe, "How to write a Blackwood article"

What article is "good"

First, let's define what a "good article" is in our case. A long one? A short one? The one that gets the most tips per hour?

I would propose the concept of "value" as a measure of an article's "goodness". "Value" is something useful, delightful or positive that a reader finds in an article. "Value" is something that makes a piece of writing worth reading, re-reading, bookmarking, copying, sharing, quoting and retelling. An interesting idea behind the words.

The main prerequisite for writing a good article is to have that really valuable idea to tell.

Why a How-to?

Writings come in many genres. There're news, novels, howtos, jokes, etc. You're free to choose any genre you have valuable ideas at. Though Publish0x is mostly a crypto-community, a good joke will be appreciated too, I believe.

But it's impossible to cover all the genres here and since this article is about how to write a Publish0x tutorial, I will concentrate only on how-to/tutorial style writings.

Besides, three really great things about how-to writings are that 1) good tutorials are always in demand, 2) it's relatively easy to find an idea for a good how-to, and 3) writing a tutorial is more a matter of technique and not of inspiration, wit, erudition or alike.

What a How-to is

The main goal of any how-to is to solve a problem. For example, anyone who has a problem with patching KDE for FreeBSD will probably go into the internets and will google for a manual about "How to patch KDE for FreeBSD". The manual then will explain all the process, step by step.

So, before starting to write a how-to it's better to make sure that the problem really exists. It's hard to write a good tutorial about a non-existent problem. For example, will a lot of people really read something like "How to install Brave browser on Windows 10"? And how many of them will bookmark it for future use? Of course, you can write a nice long detailed manual on the topic, but it will be much like cracking nuts with a sledgehammer. "How to install Brave and make it show ads when you're in an ad-disabled location" is much better indeed.

When the problem is identified, you have to show the reader a really working way out. There's nothing worse than a how-to with a tail of comments like "I do everything exactly as you say, but it doesn't work..."

Creating the body of a how-to is a simple and straightforward task: you simply describe what must be done to solve a given problem. Carefully, step by step, without missing any important details, so that the readers can repeat the procedure correctly. However, "over-detalization" is as bad here as "under-detalization". "Who talks too much, proves nothing", after all. "Keep it as simple as possible, but not simpler", as Albert Einstein allegedly said. Personal experience is a great advantage. Believe me, it's clear from the first sentences whether the author tried the suggested solution himself, or simply reworded several paragraphs from the internets. A touch of personal experience adds credibility, and with credibility comes popularity and trust.

By the way, there's a reliable rule of thumb which I always apply when I think of a how-to. When I run into a problem and can't find any good ready-made manual on the internet -- I know that it's possible to write a good how-to on the problem! Simply because I'm an average, so if I run into the problem -- millions of people probably run into the same problem too and are eager to know a really working way out.

The technique of writing a How-to

Creative writing is pretty much a matter of technique. I believe even professional fiction writers like Ernest Hemingway, Orhan Pamuk or J.R.R.Martin have their own writing techniques.

Anyway, personally I have neither any writing talent nor much imagination or storytelling skills. When I have to write something (say, memos, reports, or manuals, which I have to write not only for Publish0x, but also as part of my full-time job), I almost always follow one and the same simple technique:

First, I break the whole big idea I want to express down into smaller pieces and for every piece I put down a short title, remark, note or slogan illustrating the main idea of the piece. These marks will later become paragraphs and chapters. 

Then I start putting flesh of words on the skeleton of marks and slogans. I don't try to finish a complete chapter at once. Instead, I put some words around that note, then some around this remark, then come back, go forward, re-read, re-write, add something here and delete there. The article grows somehow chaotically, depending on what exactly I can talk about at this very moment. But the skeleton of remarks doesn't let my writing slide into complete chaos.

And at last, I see that I put down all the words flesh I wanted around all notes I've made, expressed all the ideas I had, rearranged everything to look like I see it right, corrected all mistakes -- the article is nearly ready, only a few final touches like formatting and title are left!

On language, style, and formatting

Being a non-native English speaker, I can hardly tell anything meaningful about good language and style to be used in an English tutorial. So my language note here concerns mainly other non-English writers and mostly ones with the same language skills as mine (rather limited, to be honest).

During my translator career, I learned that the key to successful inter-language communication is simplicity. In other words, try not to use fancy words and complicated sentences, especially if you're not sure about proper meaning or grammar. From my experience, I know that any native English reader would prefer simple broken English to complicated broken English (btw, it's true for any language).

Also, I would recommend using editing tools. Online dictionaries may be worse than paper ones but are still better than nothing. I use a tiny writing assistance plug-in called Grammarly to check my writings for spelling mistakes on the fly. However, personally I'm strongly against using things like Google Translate to make translations "in bulk".

Language simplicity is beneficial for how-tos in general too. A manual isn't a philosophical monograph or a fiction novel, there's no need to use metaphors or fancy words. A manual must be straight, easily understandable and to the point.

The same is true for formatting as well. Using capitals, dots, commas, and paragraphs goes without saying. Otherwise, use anything that makes your manual more clear and understandable. That is, use bullet lists, bolds, quotes, subheadings, italics, and I don't know what else whenever they are necessary. And don't use them just for sake of themselves, just because some internet guru said that an article must have a bullet list, a numbered list and a handful of italicized bolds. When used blindly, all those fancy things only distract attention and spoil your writing.

The same is true about images. Using an image to illustrate some difficult detail is good. Using images just for sake of having images because yet another internet guru said you must have images is bullsh*t. One image is worth a thousand words, they say -- ergo, one bullsh*t image is like a thousand bullsh*t words.

You name it

Title (heading, headline) is an important part of almost any writing and deserves some additional words.

The title gives the reader the first impression of your writing -- and you're rarely given the second chance to make that first impression, especially when an ordinary internet reader routinely sees hundreds of various titles daily. The title must make the reader click the link and read your writing (or "to read your first sentence", as Mr. Ogilvy or someone of those marketing guys once put it).

I know two approaches to naming a manual: a simple one and a not-so-simple one.

The simple approach is... hmm, simple. You simply name your manual after what it is about. For example, "How to patch KDE for FreeBSD" or "How to install Brave browser and get free BAT". Such titles do look kinda dull, but so many great howtos are named this way and so many Google searches of "how to ..." are made daily, that the whole tutorial genre is named simply -- Howto.

The not-so-simple approach is about creating a catchy title, i.e. a title that catches a websurfer's attention while he's browsing the web. For example, something like "Want free crypto? Install Brave!". That's where all the marketing mumbo-jumbo comes into play. Challenge, intrigue, seduce the reader, do everything to make him pick your title from dozens of others! Clearly, some people are more gifted than others at composing catchy titles, but also clearly I'm not the one that gifted, so I actually can't say much on this topic. I can only note that catchy titles imply some originality, and it's hard to be original when you're the 10-millionth one following the advice to "always use numerals in your titles".

This is the end

So my article comes to an end. It's really that short and simple. I hope I could show that writing a good tutorial is not rocket science at all. It's even easier when it goes about crypto-sphere -- so many cool things here scream for good howtos, and even more new such things are to come.

Of course, writing a tutorial my way looks a bit dull -- and so it is. But it's really effective, both for writers and readers.

Alternatively,

Or I could be a poet
And write a different story,
One that tells of glory
and wipes away the lies.
Into the skies I'd throw it,
The stars would do the telling,
The moon would help with spelling,
And night would dot the i's.
I'd write a verse, recite a joke
with wit and perfect timing.
I'd share my heart
Confess the things I yearn
And do it all while rhyming.

Shrek ("Shrek, The Musical")