Welcome to the new week!

The biggest challenge in understanding new technology or practices isn't the time needed to learn them.

A much bigger challenge is unlearning the practices we've been using so far.

Learning new technology can be challenging for many reasons. Complex APIs, unfamiliar patterns, tricky concepts, etc. But that's not really it. The real problem is that our brains are wired with years of solutions that worked before. We've built intuitions, developed gut feelings about what's "right", and gotten comfortable with certain ways of solving problems.

When a new approach contradicts these intuitions, our first reaction is usually resistance:

"That can't be right"

or

"There must be a better way"

We waste time trying to make the new technology work like our old tools instead of understanding what makes it different.

Too often, when we see new, we think hard.

The Challenge of Unlearning

Let's take document databases as an example. Many developers coming from a relational database background immediately ask:

"How do I do joins?"

The real answer is simple but uncomfortable:

“The neat part is that you don't.”

And this realization should lead to deeper questions. Instead of thinking about joins, think about access patterns. Who's reading this data? How often? What parts do they need together?

Consider a game matchmaking system. In a relational world, players, teams, matches, and game stats would be in separate tables, joined together for each query. The traditional mindset tells us this is the "correct" way. We should normalize everything and avoid redundancy at all costs. But let's challenge this thinking.

In a document database, you might store the match document with embedded team compositions, player stats, and match outcomes. Yes, player data is duplicated. Yes, updating a player's username means updating multiple match documents.

But let's think about what actually happens in real games. How often do players change their usernames? Even in games that allow it, it's a relatively rare event. When it happens, it's acceptable to take a few seconds to update historical matches - because that mirrors the reality of how games work. Players care about finding their match history, analyzing their performance trends, and seeing their progression over time. They don't care if their old username takes a moment to update in historical matches.

This isn't just about technical choices; it's about matching our data model to reality. When players browse their match history or when you're analyzing game patterns, you have all the context in one place. Each match document tells a complete story: who played, what happened, and how the game unfolded. This natural alignment with real-world usage patterns often leads to simpler, more maintainable systems.

The Art of Gradual Transition

The process of unlearning doesn't mean throwing away everything we know. When we try to force our old habits into new technologies and practices, we often end up hurting ourselves.

Take Event Sourcing. It's a simple pattern, almost primitive. Instead of overwriting the state, we record a new event. When we need to execute business logic, we fetch previously recorded events, interpret them, make a decision, and record another fact.

An event store is really just a key-value database in which the key is the record identifier, and the value is a list of events.

That's it.

But this simplicity opens up so many possibilities and potential integrations. Suddenly, it feels like our brain might explode. The old way was comfortable and we could run on autopilot. Here, we have to think, analyze, consider, and keep learning.

Let me share another journey: I used to be a JavaScript and TypeScript hater. I came from a C# and Java background. I tried to use them precisely, like C# and Java. The syntax looked similar enough that it seemed natural to apply the same patterns. The result? Pain and frustration.

The breakthrough came when I realized that JavaScript, despite its superficial similarities to C# and Java, is fundamentally different - and much more suited to functional programming approaches.

This realization highlights a common pitfall. Some people (and the tools they build) attempt to blindly transplant patterns from other environments without considering the local ecosystem. While they might offer a quick start for developers coming from specific backgrounds, they often stop at that first iteration without truly embracing the platform's natural conventions. It's like forcing square pegs into round holes - it might work initially, but it creates friction in the long run.

Starting Where You Are

The key is to begin your journey from familiar territory and then iterate based on real experiences. In our matchmaking system, when starting with microservices, don't feel pressured to break everything into tiny services immediately. Start with a single matchmaking service that handles the core logic of putting players together. Get comfortable with that service boundary, understand its communication patterns with the game servers, and let the architecture evolve naturally.e key is to start with natural boundaries in your domain. In our matchmaking system, think about what actually needs to be separate: matchmaking logic has different scaling needs than player profiles, match history queries are different from active match management. Start by separating these based on real technical or business needs, not theoretical abstractions.

Don't create artificial boundaries or ceremonial interfaces just for the sake of "clean architecture". If match creation needs player data, it needs player data - adding interfaces or abstractions won't change that fundamental dependency. Instead, focus on keeping the data flow clean and explicit. This makes it easier to understand and change the system when real needs arise.

Look for similarities between what you already know and what you're learning. When moving to document databases, you'll notice that a document is like a denormalized view of your data - something you've probably created before with JOINs. The difference is that now you're storing it that way. Or in event sourcing, if you've ever used database triggers or audit logs to track changes, you're already thinking about events - you're just making them the primary source of truth now.

For document databases, start by thinking about how you'd create a view of your data for a specific use case. Your initial structure might mirror your current relational model - separate documents for players, matches, and teams. That's okay. As you work with this model, you'll start seeing where this doesn't fit: maybe you're constantly joining match data with team data in your queries. These pain points guide you toward better document structures, like embedding team data within match documents.

In event sourcing, look for places where you're already tracking changes: PlayerCreated, MatchStarted and TeamFormed. These are probably lurking in your audit logs or status fields. Now, you're just making them explicit. Keep your existing business logic at first, but start expressing it with events. Instead of updating a status field to "InProgress", you're recording a MatchStarted event. The business logic is the same - you're just approaching it from a different angle.

The key is recognizing that new patterns often have parallels in what you're already doing. Find these familiar elements and use them as bridges to understand the new concepts. This makes the transition feel more natural and helps you avoid the temptation to force old patterns where they don't belong.

The Simplicity Paradox

Sometimes what seems like the most straightforward solution isn't actually the simplest. Our instinct is to solve problems directly: store the current state? Just update a field in the database. Need history? Add a status log table. Need to track changes? Add some timestamps.

This direct approach feels natural at first. But as requirements grow, we keep adding more and more patches: audit logs, status histories, temporal queries, analytics tables. Each addition seems reasonable on its own, but they pile up into a complex mess...