DEV Community

Cover image for 1000 Followers - A Blogging Retrospective
Frank Rosner
Frank Rosner

Posted on • Updated on

1000 Followers - A Blogging Retrospective

Introduction

I wanted to start blogging for a long time but I never managed to decide on a topic. In addition to that I didn't know where to publish. In my opinion, learning something should be the main motivation for writing a blog post and thus a personal blog should be perfectly fine to get started. However I also thought how much fun I might be missing if nobody is there to discuss about the posts afterwards.

This is where The Practical Dev comes in. I stumbled upon it on Twitter and realized it has a great community. And a great community to share thoughts and discuss with was what I was looking for. So my task was to provide quality content and join interesting discussions. At that time I was also looking for a job and felt extra motivated to be able to show some of my posts during the interview process.

It was October 2017 when I finally started writing my first post. I recently passed the 1000 followers mark and I would like to use this blog post to reflect and share my experience.

The remainder of the post is structured as follows. First I want to share the technique I developed that helps me to keep writing and finishing posts. Afterwards I want to pick a few of my more popular posts and discuss what I believe made them more appealing than others. I want to close this post by summarizing the key learnings from the past 10 months of blogging.

My Blogging Technique

I authored and co-authored a few research papers and theses during my time at the university. I also read a book and took a course about scientific writing and peer reviewing. Nevertheless writing my first blog post felt awkwardly slow.

I was not sure what to blog about and I had taken notes on several topics that might be interesting. But whenever I tried to expand those notes I struggled for multiple reasons:

  • I thought that the topics I wanted to write about had been discussed many times before by people who know better than me.
  • When I tried to write about something I was curious about, I realized that I don't know enough details to make it interesting for others.
  • When I tried to write about something I already was an expert in I felt like I had better things to do with my time because I was not actually learning anything.

The first post I published was triggered by a discussion with a friend about software complexity. I was elaborating my thoughts and we were looking at examples I wrote just to make my point. So all I had to do was to write down the argumentation, place the examples, and write an introduction and some closing words. Tada! Looking at it now I believe the post is not that exciting but it was my first one.

It made me realize, however, that blogging isn't that hard. All you have to do is gather all the material you need and then write it down! 😅 Ok it's obviously a bit more than that but boiled down to the essentials, that's what blogging is. So I thought a bit about the reasons mentioned above that kept me from writing more posts and here is what I realized:

  • Writing something that other people discussed before is not a problem. First, you might discover something that you didn't know or the other authors didn't think about. Secondly, who gives a sh*t?! Just do it!
  • Starting a blog post before you learn something about a topic is as bad as starting it after you know everything. The key is to blog while you are learning!

From then on, every time I looked into a new library, tried a new framework, researched about an algorithm, or discussed a research paper with friends and colleagues, I took notes. If those notes were expanding and still interesting after a couple of days I already had the foundation for a new blog post. Then I needed to refine the notes, convert them to sentences and paragraphs, research a bit more, and that's it. So here comes by blogging algorithm in a few easy steps:

  1. Find a topic that intrigues you. Keep your eyes and ears open when reading papers, talking to colleagues, or discussing at the lunch table. At this point you can already choose a working title for the post.
  2. Take notes. As soon as you have more than a few bullet points, start drafting a story line by adding captions to the notes. It will most likely not be your final structure but it helps you to organize your thoughts.
  3. Go deeper. Write down questions you have or areas where you don't know enough, yet. Then start researching and keep taking notes. I cannot stress this enough. Even if something feels useless now or too obvious, write it down nevertheless. You can always delete it again if you feel like you don't need it.
  4. Cut off loose ends. At some point you will feel like there are too many things to write and if you explain X you also have to explain Y. Don't go down this road as it will block you from finishing the post. Instead, briefly mention that there is more to know and leave a reference for further reading.
  5. Formulate sentences. If your story line is more or less stable and you have bullet points for every section of the post, you should start transforming them into sentences. Group sentences together in short paragraphs based on context to make the post more readable. Don't focus too much on style like repetitions or fancy wording at this point.
  6. Add pictures and examples. A picture or example is sometimes worth more than a thousand words. Go through your post and try to add illustrations and examples at all the key points. Introducing a data structure? Draw it! Discussing an algorithm? Write it down in code! Showing off a cool app you built? Include an animation of it in action!
  7. Write an introduction. It is a common misconception to think that one starts writing from the beginning. Writing an introduction becomes super easy once all the other content is there. A good introduction should state what the post is about and why you are writing it. It should make the reader aware whether he wants to keep reading or skip the remainder of the post. I also recommend to outline the structure so people know what to expect where.
  8. Write a conclusion. I like to summarize the main ideas at the end of each post. If possible you can also discuss shortcomings or mention open points. Maybe you also have questions towards the readers that might start a discussion?
  9. Read through and improve style. Now that all the content is more or less there and formulated properly you should check for some style issues. Avoid duplicate words in short repetition. Use a synonym dictionary to make the language more vivid. However you should keep the sentences short and simple so they are easily understood. Good style does not mean complex sentences.
  10. Finalize the title. Check if your working title is still accurate. Maybe you want to make it more catchy without being clickbaity. If you are publishing on The Practical Dev, make sure to choose appropriate tags as well.
  11. Publish. And tell the world! Don't be shy to share and ask for feedback. When receiving feedback, avoid defensive behaviour and take it as an opportunity to improve and develop yourself.

It may sound easy, or not. But I can tell you that practice is what makes you better. I looked back after every post and tried to find ways to improve. With every post it became easier and now, 20 posts later writing is more or less automatic and I am able to focus only on content.

Nevertheless not every post will be successful. Maybe you wrote something some time ago and reading it today makes you cringe. But that's ok. You learn from your mistakes. Let's look at some notable examples from my blog in the next section and discuss what made them stand out from other posts.

Blog Posts

Out of the last 20 blog posts you will find some about algorithms, about organizational topics, about computer architecture, software architecture, programming languages, data engineering, and so on. It became this diverse because I like to learn about many different things but I always tried to make it as interesting and understandable as possible.

So here you go with a few "gems" from my "portfolio":

Longest Series

My latest and longest series came to life very recently. In my previous job I was working with a private cloud provider so my AWS knowledge became a bit rusty. I wanted to polish it up but "Hello World" examples are a bit boring. Instead I came up with some real-world inspired example use cases. You should definitely check it out if you want to get started with AWS.

Most Popular Series

This was my first try to write more than a single blog post about one topic. I was reading a paper and wanted to discuss it with some friends over lunch. Turned out that there was so much material to write about so I ended up splitting it into four parts. The first part discussed the paper and the other three parts went deeper into each type of data structures discussed within the paper.

Most Reading List Additions

Another post inspired by a paper. It turned out to be very long because I wanted to explain the phenomenon in a very detailed and understandable manner instead of just scratching the surface. This is probably also why it ended up being the post that got the most reading list additions because it was too long for people to read immediately.

First Post Featured Externally

Last but not least I want to highlight the first blog post that was featured outside of The Practical Dev. I wrote it more or less for fun because I wanted to share some things I discovered while completing exercises in a programming language I was considering myself to be an expert in. People seemed to enjoy it and it got featured in an online Scala magazine, for example.

Of course there are more posts than the ones mentioned in this section. So feel free to check them out by browsing my profile. In the next section I want to discuss a few key learnings I took away from my blogging activities so far.

Key Learnings

Quality content takes time. First I quickly realized again how much time it takes to produce quality content. I think on average I spend around 20 hours per post. This includes reading, experimenting, coding, writing, polishing, creating figures, etc. There are posts that took longer and others I wrote in a few hours. It is probably not necessary to spend so much time if you are solely writing it for yourself but I also frequently use my posts as references in discussions or when explaining something to my peers.

Getting started is not easy. When working on something new it usually involves moving out of your comfort zone. By doing this often however you become more comfortable with moving out of your comfort zone, making the out-of-comfort-zone-movement your new comfort zone. Blogging about something I do not know, yet, helps me to keep going more than I would without the motivation to finish the post.

Reserving regular time slots keeps you going. I tried to dedicate a few hours per week to blogging. However I was most productive when reserving a fixed time slot instead of blogging when waiting for my code to compile. You are very lucky if your employer grants you blogging time. Feel free to check out the blog of the company I am currently working for: codecentric blog.

Blog series are fun. When writing several connected posts you don't have to look for a completely new topic every time. Also people told me it was fun to follow along and that they were already looking forward to the next part.

Last but not least I want to say that I think it is very important to give credit to other authors for their ideas. So whenever you are directly or indirectly citing someone else's work, please mark it accordingly. Also your readers will enjoy the references for further reading.

Thank you for reading my stuff. Thank you for commenting and helping me to make better content. Thank you for being an awesome community!


Cover image by Chris Wightman CC BY 2.0, via Wikimedia Commons

If you liked this post, you can support me on ko-fi.

Top comments (4)

Collapse
 
husterknupp profile image
Benjamin Schandera

Just had this in my inbox and thought of your 👍 article
zellwk.com/blog/writing-good-codin...

probably you know most of it already. I liked Zell‘s emphasis on how you should make your reader feel that she can actually accomplish the same results that you’re talking about in your article as oposed to leaving the reader with the feeling that she‘s too dumb for this stuff.

Great work!

Collapse
 
aspittel profile image
Ali Spittel

Congrats!!! I really like your tips in here!

Collapse
 
ben profile image
Ben Halpern

Love your stuff here Frank.

Collapse
 
gameoverwill profile image
Wilfredo Pérez • Edited

Thanks for your post, and congrats for reaching the 1K. I'll use this recommendation soon althought I was thinking about write something I needed this advices.