A year of blogging

31 December 2023

In January 2023 I decided to start writing a technological blog, mostly about field of my profession which is DevOps, Cloud and Infrastructure. I had this idea in mind since some time but was hesitant to do so. My greatest fear was writing something stupid. I decided to ask colleagues how do they manage to create their content. I asked Marcin from wanago.io, with whom I attended college, how did he manage to write everything without mistakes and where does he get ideas for posts. The answers are almost obvious: ideas come from wanting to learn something new and to avoid mistakes - learn it as good as possible. Teaching it to others is best of both worlds: teaching is the best way to learn something and you can't explain something you didn't learn well enough. I also asked Martin what is his process for post creation - just make the post clear and to the point so that others can understand it.

Well, I hope that I didn't write anything that was a huge lie in any technology but I know some things that I wrote and they didn't make any useful sense. For example Slim app for getting SSM Parameters in Go was originally to be used to pull environment variables for ECS from SSM Parameter Store. Long after I learned about valueFrom in the task definition that does exactly that. Somehow coincidentally, I wrote about using it locally or on EC2 without ECS Agent, so that post didn't make so much nonsense.

Reasons to start blogging

My largest motivator to even consider blogging was to create some credibility in the DevOps/Cloud/SRE world. I wanted to have something to show, not just what I had in my CV. I often chose things I never used at work, just to learn them. That way I could present that I'm not doing things only that are required of me but make some initiative.

Other things were to learn for the AWS Certifications that I took up mid-2023. Aurora Backtracking and CloudWatch Metrics? No, thank you. Timestream (feat CloudFormation)! were a great way to learn Aurora, Timestream and CloudFormation for AWS Database Specialty. Recover SSH Access on AWS EC2 Instance was a fresh exercise for Security Specialty.

However, process of writing this blog wasn't without mistakes. Let's go though some of them.

Mistake #1: lack of journaling

I tried multiple styles of writing: serious tone, humorous tone, adding some book references, etc. Some posts contained videos and animated gifs, some were just text with screenshots here and there. Now it would be a good time to write which style is the most enjoyable, which is the easiest.

I don't remember.

I never noted down how I feel about writing each post, how much time it took me. This is crucial because if I knew which style I like, that would help me write further posts easier and faster.

Mistake #2: planning and cadence

In 2023 I wrote in total 35 posts (making this one 36th). The goal was to write every 10 days. I missed one post in December but this still rounds up to the target of 36 planned. On the other hand, my writing process wasn't without obstacles. Some posts I wrote were done a day after the deadline, some were written in advance. Some posts I was writing every day for a week, others were just written for the last moment in several hours.

One of the optimal ways to write would be to:

1. Get an idea.
2. Research and create an entry plan in 15-30 minutes.
3. Write two paragraphs a day for 4 days.
4. For things that require time to happen (like Google Play metrics updated once a day), write more paragraphs in advance and continue after the experiment. Or even do the experiment in parallel with another post.
5. Based on gained insights, revise the plan.
6. Write the rest of the post in 3-4 days.
7. Review and publish.

Another approach would be to write everything in one run, but for that I would need to have a ready idea and project to present. It was possible for example in case of Easy MFA in AWS CLI where I had a ready project that I used at work and I just needed to write about it. But this isn't always the case. Some things would be too long to write about and others would bd too trivial or "there are already 1337 articles about it".

Learning #3: READMEs and comments are important

Writing this blog also helped me realize outside of this scope how important are READMEs, comments in code and well formed Git commits. Since I started writing here and publishing the projects for the posts on GitHub, I gave more attention to writing READMEs, comments and commits like to a person that is just starting.

On one hand, the person inheriting project after me might waste time on reading for too long but in most scenarios reading this amount of text takes less time than figuring out what does function calculateResult(int a, Object handler) do.

Project I published on GitHub have very short READMEs but in each case, I added a link to a blog post which explains even more than needed.

As a proof of the above, I personally used my blog to remind myself of some solutions. For example, I didn't remember how to mount an EFS disk to ECS task. I opened my post Nextcloud on EFS and ECS and quickly adapted the code to my needs.

Plan for 2024

Despite these learnings, I decided to lower the pace in the coming year, as my primary focus is now to gain a complete set of AWS certifications. For this blog, my goal is to write 16 posts in total next year, making it four every quarter. The same pace I would set for books - 4/quarter.

Thanks to everyone reading this.

Thanks also to amazing team at Spiele-Palast 🃏 where I have a lot of freedom to experiment 🧪 and curious colleagues that are willing to learn.

Thanks to Yujun, Yongkang, Viktoria and Sammy for the daily push towards getting certified 🎓.

And happy new year 🎉!

P.S. I want this post to have some kind of cover image. As I compile all my posts from Markdown using my own script and I don't want to rewrite all posts to include og:image, I will just leave an image here: all the free merchandise I got at AWS Summit Berlin in May. The 75% discount code I got there was also the reason I finally went to Solutions Architect Associate exam, for which I started learning back in 2020!

Many say that certifications are not needed in IT just as university is not needed - yes, if you can set a static, measurable goal for yourself - which is rare. I would have never known the advantages and problems already solved by many AWS managed services if not for certifications. Also Terraform cert gave me confidence to use it for everything, otherwise I would still never run apply because "what if production gets wiped out forever?" Making bachelor's degree helped me learn team work, scientific research, gave access to a library with advanced books on the subject. Postgraduate studies most importantly gave me the basics of machine learning, thanks to which I understand at least something during the recent AI hype (if you are studying in Gdansk and have lectures with Mr Draszawka in your plan, go there).

Just my 2 cents.