For a long time now, people have been asking me to tell them how I write my blog posts on the rtfm.co.ua. And since I’m finally going to write about it, let’s take a look at why (if) it’s good to have your own IT blog.

Why do you need to run an IT blog?

I started this blog mainly as a kind of notebook for myself – just to write down how and what I did during my everyday work, so that later I wouldn’t have to search for manuals on the Internet or write down something that wasn’t on the Internet at all.

Later on, it turned into a desire to share what a great specialist I am because the first time you build a FreeBSD kernel, you think you’re a God 🙂 That’s a big joke, of course, because the first time I built a kernel was in 2007, and I did it like a “monkey with a manual” – reading posts on other blogs, copying commands and configs, but understanding very little.

In fact, as I’ve gained some experience, blogging has given me another important bonus – it helps me fight my own “impostor syndrome” because even after (OMG!) 18 years in IT, this syndrome hasn’t gone away, and I still sometimes think, “Shit, did I just write a bullshit?” However, when your posts are liked by Solution Architects from Oracle, it really helps you to feel like a human being.

Your own brand

I would put this last in terms of importance, but for some reason I want to start with this.

Your blog is your brand.

Very often, especially in the last 6–7 years, when I came for an interview, I heard “Oh! So you are the administrator of that RTFM? Cool – I found a lot for myself there!”

That is what a personal brand is – when you are recognized as a specialist.

Some people speak at conferences, but I’m too scared of the public. And someone quietly writes a blog, where, of course, there is also an audience, and sometimes they give me “minuses” – but at least it’s not personal.

And here we come to the second point:

Your personal development

I can’t imagine doing any complex task without making notes in a draft blog.

Writing is all about structuring the information you receive. You need to present the information in a way that others can understand, and to do that you need to be able to connect all the ‘components’ of the post in your own mind.

It really, really helps you to understand something new, to memorise it, to better realise all the “moving parts” of the new system.

And here is another important point. Once upon a time (I even remember this post – Apache: MPM – worker, prefork or event? , 2012) I showed my new post to a sysadmin friend of mine. He’s a very sophisticated guy.

After reading it, he said to me something like, “Well, yeah, it’s cool, but here and here it feels like you don’t really know the subject”.

It was then that I realised that, damn it, I had to dig. You can’t just pick it up and write it. You have to write thoughtfully, knowing what you are doing and why.

And that need means that when you’re dealing with a new material, you can’t just skip over a bit that’s not very clear: “Oh, I’ll figure it out later or whatever”.

No! You have to sit down and figure it out. And this is what really helps in your own development as a specialist because later on, when you are asked about a topic in an interview, you can reveal some details of that topic, show that you really understand the topic, and not just “skimmed” the documentation, copied the commands, started the service, and start thinking you know it.

In general, attention to detail and the ability to understand what’s under the hood is very helpful in your work. Because only if you know HOW the system works, what’s going under the hood, can you understand where to dig to fix it.

Going back a bit to the “write thoughtfully, knowing what you are doing and why” – this is a habit in blogging that has already become a habit in work: you can’t just “take it, do it and forget it”. You have to understand what you’ve done and how you’ve done it, firstly because you’ll have to maintain that system later, and secondly because you’re responsible for what you’ve done. And given that our work as DevOps Engineers is very much related to infrastructure, to the “foundation” of any project, to all its data, a sense of responsibility is essential.

Your own documentation

I often, very often, go back to some old posts to see what I did, and how I did it. This helps both when you’re setting up an already familiar system on a new project, and when you’re trying to figure out what’s broken on the current one.

Also, your colleagues have access to information about how you set up a system, and when I was a Team Lead, my guys often used the RTFM to figure out something I had set up.

Of course, blogging doesn’t mean that you can skip the “local documentation” somewhere in the project’s Confluence, but your blog is a much better way of describing what you did and why you did it, and why you did it this way and not that way.

How to run a blog?

The first and foremost thing I thought about when this blog started was this:

What should I write about?

And now the answer is the same as it was then: about what you’re doing, what you’re facing, or what you don’t really understand, and you have to figure it out.

But perhaps the most difficult thing is to create the structure of a new blog post – to understand what to write about and how to arrange it – what relates to what, what to write about first, what to write about second. What to put in a separate part, and what is enough to write a few sentences about.

Screenshots will be in Ukrainian/Russian, as first I’m writing in my native languages

For example, here’s how I “mentally prepared” for writing this post:

Information structure

Even now, when I write this material, I re-read it and divide it into parts with (sub)headings so that they somehow logically break down everything that is written about.

Here’s another example from the old drafts:

You start writing about one thing, and then you realise you need to write about something else, and then something else… And as a result, you are sitting in front of a million tabs in your browser and your head is a mess. But you still have to get your head together and get it done and present it in a way that the person who is going to read this material will understand what you are really doing.

Or here’s one more example:

Here, at the beginning of the article, I outline what exactly I will be talking about because it helps me to keep the “thread of the story” in mind.

Understand the topic!

Yes, you need to understand well what you are writing about. But you shouldn’t be afraid to write (because “what will people think?!?”) either.

Here’s another example of how the process of writing some posts sometimes looks like:

Again, you can’t “just do it”, you have to figure it out.

Another thing to mention is the length of posts: it’s better to avoid “towel posts”. It’s better to divide a post into several parts, each describing a part of the topic, rather than trying to cram everything into one post (although sometimes I do it that way).

This helps both when writing because it makes it less confusing, and when reading because it makes it less confusing for the reader.

Blog languages

If you have the opportunity, it is better to write in English.

First of all, it’s cool.

Second, you are not limiting yourself to readers from your country.

Thirdly, it is a very cool English exercise.

When it comes to spelling and mistakes, the main thing is to be understood. You can also use plugins like Grammarly or LanguageTool, and even Google Translate.

There are also great solutions to help with translations such as Reverso Context, Reverso Grammar Checker & Rephraser, and Deepl.

Where to keep your blog?

There are plenty of options here – from ready-made platforms like Medium, to your own VPS with WordPress.

I once chose to run WordPress on a dedicated VPS so that I could gain additional experience in Linux administration and all sorts of Apache/Nginx/PHP/MySQL stuff – and it was really useful.

Another thing to keep in mind is that when you blog on platforms like Medium, you’re really entrusting all your information to them, it’s a kind of “vendor lock”, and it can be very painful to migrate from one platform to another, especially if you have a few thousand posts.

Actually, the same applies to some self-hosted platforms like Jekyll – if the Jekyll developers abandon it or change their pricing policy (or licencing – hello, Terraform!), you may be left with a broken trough.

And in this respect, WordPress is more than suitable for me because the platform has been around for many years, and now it even offers to register for a hundred years in advance (The 100-Year Plan on WordPress) – optimists 🙂

Conclusions

Is blogging worthwhile? For me, the answer is obvious because it really helps me in my work, in my own development, and in my career.

However, you have to be aware that it takes time. Some posts on the RTFM take a week or more to write, and then another day or two to translate into English.

You also need to understand that it will take time for your blog to be read by people, and that you may get a few random visitors per day for the first few months.

However, the benefits of blogging are well worth the time.

Even if no one reads your work, you will learn how to express your thoughts, present information, or improve your English. You will always have your own documentation. You will have a much better understanding of what you have done when you write a new post.