It has been a while since I started thinking about opening a blog. That included many failed attempts that never saw the light for several reasons, including myself being lazy. But this time, here we are.

In this first post, I want to go through some of the main reasons I got here and what I plan to do with all this empty goodness. I hope you’ll enjoy it!

The technical stuff

The first and most significant aspect of this success is this blog’s simple and easy technical setup, thanks to GitHub Pages and Jekyll.

If you’re a backend person like me, you’ll understand for sure the pain of dealing with WordPress (or any other blogging platform, for that matter). Themes, plugins, and editors all seem to fight your already little motivation to write. And, in the end, you give up with no content and a bizarre-looking website that you’ll throw in the trash in a couple of days.

So you can imagine my happiness when I found a way to write posts in plain “old” Markdown, with very little scaffolding to go from text to a published website. And it comes with a beautiful, minimalist theme like this too.

It’s a real blessing. So, thank you, GitHub/Jekyll team!

Not your average self-help book, I guess

But solving technical problems isn’t everything (more on that later), so I had to confront myself with another chronic pain that we all experience: fear of failure.

Why should someone even bother reading my blog? How can I be relevant in a world flooded with every kind of digital content? If nobody’s going to read, why should I bother posting in the first place?

It takes some time to realize that those mental paths are toxic and they limit your creativity and ability to discover and improve, but it comes down to a simple and easy fact: you need to try. After all, how can you get better at something if you never get your hands dirty? So I’ve finally chosen to roll up my sleeves and start creating something.

And, of course, I have a plan.

Ok, then why should I bother?

I’m glad you asked, dear reader. Even though this question shouldn’t demotivate you from writing, we must realize that in a world where everyone can post, having effective communication is vital. And to get that, you need to find your unique proposition and values. So what is mine?

As you know, there are already hundreds and hundreds of blogs and websites that teach you how to do stuff in the tech world. Want to learn how to build a NodeJS API? Just search on Google, and you’ll be overwhelmed by the number of results. Want to learn SQL? Well, we’ve been collecting materials since the 70s about this topic!

Don’t get me wrong, that’s a real treasure, and I find myself using those resources more often than I would like to admit, and I’m sure you do too. The fact is that with so much great content is easy to be redundant and, in the end, waste your effort.

But I often find one particular area lacking in technological space, which has too little visibility in my opinion, and that is real, opinionated, and trustful guidelines about how to build systems the right way.

Wait. What do you mean by “right way”?

I see lots of colleagues and developers in general so busy checking in code and closing Jira tickets that they forget the basics of computer science. They think about fast and easy solutions to problems, but they fail to slow down and abstract their thought on the overall design, and that’s how we come up with legacy code.

This concept isn’t new by any means; Bob Martin explained it thoroughly with his “Clean Code” and “Clean Architecture” projects, alongside many others. The fact is that these methodologies are still too little widespread, and I see a large gap between the conceptual work and the day-to-day work of most developers and engineers.

You can learn how to create a basic NodeJS Web API with an online course, or you can learn high-level concepts in talks from the big gurus of Computer Science, but you usually have to figure out the gap on yourself.

I’m here to (try) fill that gap.

And so?

So my promise and my goal for this blog are to provide you real-world experience (made by my mistakes) that can help you better understand the integration between high-level concepts and the day-to-day work of a software developer/data engineer. Batteries included.

I’ll have strong opinions on stuff that matters, and I sincerely hope you will stay with me during this journey. If you so want, I suggest you subscribe to the RSS feed of this website or follow me on socials to get notified about my future posts.