About Me

In a world full of AI hype—from chatbots that write code to flashy demo applications—I always felt that most tools were geared toward niche use cases like building QA bots or RAG agents. What really got me excited, however, was discovering a game-changing application for production-scale, non-AI companies: using LLMs to revolutionize ETL processes. Traditionally, both the data source and the target had to be strictly structured. Data engineers spent countless hours writing code to map input data into a very specific schema. With LLMs the input data can be completely unstructured, and the model takes on the heavy lifting of transforming it into structured, usable data. ...

I recently read this article about a lightweight durable execution solution called DBOS. Meanwhile, I was working heavily with Temporal, a well-known open-source tool for durable executions. Technically, both serve the same purpose, but with major differences: Temporal is heavyweight. To run it, you need a Temporal cluster, a database connected to the cluster, one or more Temporal workers, the Temporal UI, and finally, the Temporal SDK to trigger workflows from your application. On the other hand, DBOS is lightweight and requires only a database to store its data. The workflow runs within the same application that includes the DBOS library, whereas in Temporal, workflows run on separate resources called workers. Essentially, DBOS is a library, while Temporal is a full-fledged software solution that you interact with via its SDKs. ...

In my previous job, I conducted multiple technical interviews, and one of the key questions we asked candidates was: “If you have a database and a query takes longer than required to run, what would you do?” After discussing their response, we would follow up with: “Now, what if the load on your database increases? What would you do now?” This question helped assess whether the candidate could scale a database effectively without over-engineering. An immediate mention of CQRS in the first round was often a red flag—indicating they skipped simpler solutions and jumped to complex ones. We also valued candidates who asked clarifying questions before proposing solutions. Jumping into an answer without knowing the QPS (queries per second) or required response time was another bad sign. ...

I recently read this text on social media, and here are my thoughts. I both agree and disagree with it. But first, let’s align on the terminology. Based on the definitions in this text, a “real” software engineer is someone who builds tools and understands how they work. On the other hand, someone who reads the documentation of tools and connects them together is called a “blue-collar tech worker.” While one could argue about whether this term is accurate or not, let’s go with “blue-collar tech worker” to make it easier to discuss the differences. ...

For the last three months, I’ve been diving deep into Kubernetes as part of my new job, and I decided to write this blog to share my journey in learning Kubernetes. If you work in a DevOps role or your company operates on Kubernetes, understanding it inside and out is essential. However, as a software engineer, I also encourage every other software engineer to learn Kubernetes. Here’s why: The Rise of No-Ops With the growing popularity of cloud solutions, there’s a noticeable shift from DevOps to No-Ops. Catching this trend early can put you ahead of the curve. The Transformation to Generalists The job market is evolving, thanks to advancements in GenAI and LLMs. Specialized roles like “Django Back-End Developer,” “React Front-End Developer,” or “DevOps Specialist” are increasingly giving way to more generalist roles. Today, I see more “full-function software engineers” whose responsibilities include designing solutions, coding both client and server sides, configuring builds, deploying to production, and delivering the final product. Based on this, I believe it’s becoming crucial for software engineers to develop cloud and Kubernetes skills. A Masterclass in Design and Architecture Kubernetes’ design is elegant and showcases some of the best practices in software architecture and design patterns. When you explore its components, it’s like watching Lego pieces come together to form a self-reliable infrastructure. The way Kubernetes uses separation of concerns and well-defined abstractions is inspiring—it’s no surprise that it has become the new standard for cloud and DevOps. All that aside, these are the resources I found most useful for learning and working with Kubernetes. ...

I was recently introduced to dagger.io by my tech lead. Dagger is a CI tool created by Solomon Hykes, who is also the founder of Docker. I listened to his interview on the kubernetes podcast and several aspects about the motivation behind Dagger caught my attention. The most interesting aspect of Dagger is its objective to provide a separation of concerns. These days, the CI code and configuration you write are often tightly coupled with the specific technology or infrastructure you are using. For example, gitlab-ci.yaml files are tailored for GitLab runners, and GitHub Actions has its own unique file format. Dagger aims to unify CI pipeline configurations and code, making them executable anywhere—similar to Docker. ...