sergiolema

I see many junior developers struggling to land their first role right now. AI is effectively doing the job of a junior developer. It churns out boilerplate, basic CRUD operations, and standard algorithms faster than any human can type. However, if you look at the job boards, there are still plenty of software engineering openings.

The industry has a new problem: AI has flooded codebases with a lot of crappy, unoptimized code that must be fixed. Companies are now looking specifically for senior engineers because they need people to clean up the mess that automated tools leave behind. If you are a mid-level developer who wants to stand out and secure your position, you must be demonstrably better than the AI.

We start using Google Cloud Run for the right reasons: it is cheap, it abstracts the nightmare of managing a Kubernetes cluster, and it speaks Docker natively. For a simple API, it is unbeatable. However, as requirements evolve toward high availability and large file processing, the "simplicity" of serverless begins to look like a distributed monolith with too many moving parts. If you are fighting the platform to implement basic features like file uploads, you have likely outgrown the service.

After 15 years in this industry, I have developed a very low tolerance for "ceremony." If a project takes more than five minutes to move from a git clone to a running development environment, it is poorly designed.

After 15 years in this industry, I have developed a very low tolerance for "ceremony." If a project takes more than five minutes to move from a git clone to a running development environment, it is poorly designed.

This post breaks down the reality of Spring’s transaction management. After 15 years of seeing the same production fires, it is clear that most developers treat @Transactional as a "set and forget" magic trick rather than a sophisticated AOP proxy.

Stop treating microservices like a trophy. They are a tax.

We’ve been told they "decouple" teams and solve scaling. In reality, most companies are just trading code complexity for operational nightmares.

In a monolith, your enemy is messy code. You fix that with a refactor. In microservices, your enemy is the network. The network is slow, unreliable, and breaks in ways you cannot easily test.

If Service A fails because Service B is down, they aren't decoupled. They are just far apart—tied together by a wire and a lot of latency.

We’ve replaced 5-line ACID transactions with the *Saga Pattern*, manual state machines, and "Eventual Consistency" (which is usually just a fancy way of saying the data is wrong and we hope it fixes itself).

Why do we do it?

* Resume-Driven Development: Building complex systems to look "expensive." * Cargo Culting: Copying Netflix's architecture when we have 10 engineers, not 10,000. * Sunk Cost Fallacy: We spent 6 months on the YAML files, so we have to use them.

*The hard truth:* If you cannot write clean code in one repository, you cannot write it in twenty. If your monolith is a "Big Ball of Mud," microservices will just be a *Distributed Big Ball of Mud.*

I’ve written a breakdown of why we need to stop the over-engineering and how to actually audit your architecture.

Stop using 50MB frameworks to manage one single instance of a Logger.

Most developers think they know how to write a Singleton. They read a blog post a decade ago and haven't checked if that information is still valid for the modern JVM. The result? Production code filled with thread-safety issues, memory leaks, and "Senior" implementations that are actually maintenance liabilities.

We’ve moved from "Singletons everywhere" to "DI frameworks for everything," but we’ve forgotten how to actually use the JVM.

In my latest post, I break down: - The Reality of Failure: Why "Double-Checked Locking" is often just a sophisticated way to introduce bugs. - The "Resume-Driven Development" Trap: Why we over-engineer simple patterns just to look smart. - The 2026 Standard: Why the Enum Singleton remains the only truly bulletproof implementation. - Testing Myths: Why "Singletons are hard to test" is usually a symptom of poor interface design, not the pattern itself.

Complexity is debt. Every line of extra code is something that can break at 3 AM. If you’re still writing ten lines of synchronized boilerplate for a task that requires one, you're building a liability, not a feature.

Most Singletons in production are broken.

After 15 years in development, I still see services crash or slow down because of "clever" implementations that create memory leaks and race conditions. If your JVM memory looks like a mountain range, your Singleton implementation is likely the culprit.

We have a tendency to choose complex code over simple, working solutions—often fueled by "Resume-Driven Development."

In my latest video, I cut through the fluff and look at the reality of technical debt. I cover why Eager Initialization, Lazy Loading, and Double-Checked Locking are usually the wrong choices and focus on the only two methods you should actually use in 2026.

Key Topics:

The Memory Collapse: Why "clever" code instantiates objects on every request.

The Bill Pugh Singleton: Using the Holder Idiom for thread-safe instances.

The Enum Singleton: The gold standard for reflection-proof and serialization-safe code.

Testing Reality: How to properly handle Singletons using DI and interfaces.

Stop adding complexity. Complexity is debt. Fix your code so you can actually enjoy your weekend.

When you start a new React project, the initial momentum is great. Components are flying, features are getting built, and everything feels clean. But as the codebase grows, that initial structure often crumbles. Files get dumped everywhere, components become bloated, and simple changes start to have ripple effects. I’ve been there, and it's not a fun place to be.

This is where system design for the frontend becomes essential. It's not just about backend architecture or a massive corporate process; it's a practical framework for making consistent, scalable decisions about your project's structure from day one. I believe adopting this mindset is a critical skill for any mid-level developer looking to build maintainable, long-lasting applications.

We've all been there: You've just spun up a new EC2 instance, you've got your key pair ready, and you're feeling good. Then you try to connect, and all you get is a "Connection timed out" error. My first instinct, and likely yours, is to look at the security group. Nine times out of ten, that's where the problem is hiding.

In this article, I'll walk you through the most common security group pitfalls that lead to EC2 connectivity issues. This isn't a comprehensive guide to every possible AWS problem, but a practical checklist focused on what a mid-level developer needs to check first.

We've all been there: a team of talented developers, all heads down, churning out features. On the surface, it looks like a productivity paradise. But if you look closer, you might see a team working in silos, each developer an island of their own making.

I've been on a team like that early in my career, and the results were predictable: standalone developments, poor communication, and a complete lack of shared architecture or security guidelines. The application became a monolithic mess, nearly impossible to evolve or fix. Now, of course, I would do it differently.

The common misconception is that adding more developers will automatically increase output. The reality is that without a unified direction, a team's potential is never fully realized. This is where the role of a leader becomes essential.

If you've spent any time in the Java ecosystem, you've likely encountered a confusing trio of logging libraries: SLF4J, Logback, and Log4j. Deciphering their roles and how they fit together can feel like trying to untangle a mess of dependencies. But it's simpler than you think.

Let's cut through the noise. Your goal should be to use a logging API that abstracts away the implementation details. This is a powerful design pattern that will save you from refactoring your entire codebase later on.

Database migrations are a core part of modern application development. Without them, managing schema changes across different environments becomes a chaotic, error-prone mess. For years, I've been juggling between Flyway and Liquibase depending on the expertise of the developers.

If you’ve ever had to choose between them, you know it's not always a simple decision. Each tool has a different philosophy, and what works for one project might be a terrible fit for another. I've used both extensively, and this post is my take on the key differences, helping you figure out which one deserves a spot in your tech stack.

I've developed many projects, and all the time, the decision was direct: let's create a container with Docker.

But recently, I've reached some dead-ends with the containers, so I'd to made the question: VM or Container?

While containers have become the de-facto standard for modern applications, the lines between these two technologies are starting to blur. The rise of new, security-focused container runtimes proves that developers and infrastructure engineers are seeking a middle ground. Let's break down the core differences and explore the tools that are changing the game.

We’ve all been there: a brilliant idea for a new product, followed by weeks (or months) of development, only to find ourselves with an over-engineered solution and no users. It's a common trap. We love to build, but sometimes we build too much, too soon.

To avoid this pitfall and maximize your chances of success without burning through time and money, I've refined a three-step framework. This approach is less about a rigid project plan and more about a strategic mindset: build small, validate fast, and scale deliberately.

n my React application, I have to fetch the backend to:

list the products

display the price

list the availabilities

and more.

But all the time, if an error occurs, a 4xx or a 5xx, I repeat the same logic, everywhere: display a pop-in with an error message like "Your product is no more available", "There is no availabilities in the selected dates" or simply "An internal error occurred, try again later."

But it's always the same logic. I don't want to repeat the popin and the catch of the request everywhere. That's why I use the useContext hook

Is your LLM assistant more of a burden than a benefit?

Many developers, including me, have struggled with AI models that misinterpret simple requests or overwhelm us with unrelated code. It feels like they are always in a "junior developer" stage.

But what if the issue lies not with the LLM, but with how we communicate with it?

Could the future of backend development be… no code at all? We've all seen the rise of no-code frontend tools, transforming web design from a coding marathon to a visual sprint. Yet, the backend often remains a fortress of endpoints, database schemas, and authentication flows, seemingly immune to the no-code revolution. Or is it?

Recently I've been playing a little bit about no-code tools to implement a backend. And the result was quite interesting.

Alright, let's talk about MagicMock. It's a lifesaver for testing, especially when you're dealing with external dependencies. No one wants to hit a database or an external API during a unit test. That's where MagicMock steps in, letting you simulate behavior without the actual baggage.

Testing code that interacts with external services, databases, or even complex internal components can be a real headache. You want your unit tests to be fast, isolated, and repeatable, but those dependencies often get in the way. Enter Python's unittest.mock.MagicMock – a powerful tool that lets you replace parts of your system under test with mock objects, giving you full control over their behavior and allowing you to assert how they were used.

Who's never worked on a spaghetti code? Luck you.

I've worked on sever projects that had some spaghetti code. And all this started because of a lack of structure.

A well-structured application helps you avoid that mess by clearly separating concerns. One common and effective approach is using a layered architecture.

While the number of layers can vary depending on your domain, the core idea is the same: group logic by responsibility. Here's how I typically split it.

When you're running a Java application in production, performance often comes down to how you configure memory. And by "memory," I mean how the JVM handles it—not just how much RAM your machine has.

It's easy to launch a Spring Boot app with a java -jar, but if you're not passing the right flags, you’re leaving performance—and stability—on the table. Here are three JVM parameters you absolutely should understand and configure.

Starting a new product is exciting, new ideas, new challenges, and often, the chance to build something from scratch. But before the first line of code gets written, there’s a deceptively simple question that demands an answer: Which tech stack should we use?

This isn’t just a technical decision. It’s strategic. The wrong choice can cost you months, drain your team, and force painful rewrites. The right one? It can accelerate everything.

Here’s how I think about it, especially if you’re in a leadership role trying to balance vision with execution.

Recently, I've been building a project in Python that doesn't have a Docker image as output. Instead, I need a runnable file. Why? Because I need to talk to the machine directly and not to Docker. Because I need to talk to the GPU drivers directly and not to another abstraction layer.

So, I needed to create a runnable file in Python. I needed to create a wheel file. All this with Poetry and integrate it into my CI/CD pipeline.