I'm creating the blog to share my experience building software systems and creating the path I missed when I started. I'm not ignoring AI, but I will not make it my primary topic, especially building software with agents and AI. Almost everyone on YouTube, LinkedIn, and X is currently doing it. I want to do the opposite: slow down, work deeply, and maintain my critical thinking. The product of my work lives in Software Engineering Mastery.

Don't get me wrong, I'm not against AI-generated code; I'm against blindly accepting anything produced by AI and not applying critical thinking. At work, we have to deliver and iterate fast, whereas in our personal time, we can slow down and reflect enough so that we become better versions of ourselves.

This blog will not be written via AI, but I will utilize AI as a reviewer once I finish each post, to make sure I'm not missing anything. Having your own reviewers is expensive and time-consuming, as I have reviewed a couple of books in the past for Manning. So I will use AI to assist me, while keeping the cost low.

You can always find more about my experience at About Me.

Mastery Path

The main goal of the Blog is to publish and update along the way my Software Engineering Mastery page. From time to time, I will share about topics that I research for work, but the majority of the time, I will share material needed and supporting the mastery path.

I'm taking this approach as a way to counter the effects of the AI, keep my skills sharp, and keep my critical thinking alive.

After all these years, I believe the best way to achieve this is by solving problems, and thus, I think solving projects that will teach you real skills is the best way ahead.

My goal is to give you resources that will help you grow as a software engineer. You will have to struggle and look for answers on the internet (or take the short road with AI, but I think this will not generate long-lasting knowledge).

Path structure has two main stages:

• Foundations - structured around project-solving, targeting projects from CodeCrafters. Why am I using their projects? Because I love the platform, and I think they are investing enough time to create a good product. I don't think it will be very beneficial at this point for me to create something similar from scratch.
• End Game - this is where I will build big projects from scratch, such as a Web Browser and a Game Engine. I will tackle one at a time, but I'm unsure which one to do first. I will decide when I get there.

Inspiration

I love the idea of Kaizen. I'm building my blog as a written journal of my experiences, iterating over and over until I master and understand the topic - continuously improving myself in the process.

Kaizen is a Japanese philosophy meaning "continuous improvement" (改善 — kai = change, zen = good).

Ever since I read the book Mastery from Robert Greene, I'm inspired to find a way to become a master in what I do, even though I'm not following the prescription of finding someone to follow and to guide me. Robert Greene chose figures like Leonardo da Vinci (curiosity-driven), Thomas Edison (relentlessly experimental), Albert Einstein (independent-minded), and Benjamin Franklin (self-educated). I'm fascinated by the idea of exploring their way of working and applying it to software engineering.

“Over the centuries, people have placed a wall around such mastery. They have called it genius and have thought of it as inaccessible. They have seen it as the product of privilege, inborn talent, or just the right alignment of the stars. They have made it seem as if it were as elusive as magic. But that wall is imaginary. This is the real secret: the brain that we possess is the work of six million years of development, and more than anything else, this evolution of the brain was designed to lead us to mastery, the latent power within us all.”
― Robert Greene, Mastery

Being good at something doesn't mean that we are born with that skill; it means that we are practicing enough so that we become Masters.

For me, software engineering is a product of multiple disciplines, which we will try to target and improve. Critical thinking and problem-solving are required in order to understand the problem and solve the correct problem. Solving the wrong problem, even perfectly, will not drive the product and company forward. Domain knowledge is how software engineers get credibility, expanding the critical thinking side. And finally, enough experience in writing programs, so that we can assess the quality of the code we review, and be able to analyze the drawbacks of each solution.

Why now?

This video from "ThePrimeagen" explains why understanding software engineering and weighing choices is far more important today than before. It revolves around the idea of "cheap" code. Being able to produce code fast and cheap means that it matters more than before which line of code we keep and which line of code we remove.

The following video has a strong statement: "Slow the F*ck Down", from Mario Zechner, who is the creator of pi, an AI Agent built out of frustration with Claude Code's growing complexity and hidden context manipulation. Just as he is, I'm concerned with the speed and the breaking changes that they introduce, which sometimes make it an unreliable product. In my own opinion, Claude Code tries to deliver all kinds of features, no matter whether they are needed or not, making it a big chimera (like the Tamagotchi assistant that sits on top of the coding sessions). Not every feature is worth building, no matter whether it is cheap or not to write the code.

And the final video that I will share is from Matt Pocock - "Software Fundamentals Matter More Than Ever". Matt Pocock talks about why we must know the basics. On top of that, he touches on a lot of the topics that I'm building my blog around, and how important it is for you to understand and design the code. If your codebase has lots of entropy, AI will struggle as well. He touches on the idea of "Cheap code" and explains that this is not entirely true, as cheap code can add entropy, which adds bugs and makes further changes harder - thus, code is not cheap. If you are interested and deep into Agentic Engineering, you will discover some skills and ways he uses the AI to support the creation of quality products.

I'm a father of a one-year-old with 10–15 hours a week and a belief that deep work still matters. If you're in a similar place — tired of the noise, trying to stay sharp — this blog is for you. Let's build mastery together.