Lately we’ve found an easy way around that resistance. We no longer need to try over and over to reach the solution, or review the solution in detail to see what we’re missing; language models take care of lightening that challenge. What the calculator once was, an agent is now, with the difference that the calculator did the math, but the reasoning was still ours. The agent promises to do both.

We have feared that technology would affect our intelligence ever since tools have existed. And I don’t want us to fear agents. On the contrary, used the right way they can speed up learning. AI took away the friction that used to come free with learning. Now we have to seek it out on purpose. The good news is that AI itself can help us, if we ask it for questions instead of answers.

The value of mistakes

Learning happens in the struggle to solve a problem, getting it wrong and trying again. Our brain predicts and looks for patterns by instinct. It does so with fast thinking, the intuitive kind, the kind that doesn’t ask permission. To activate slow thinking, the deliberate kind, we need to stop assuming our model is the right one. Get it wrong. This forces us to stop and think seriously.

This has a name: desirable difficulties. They make studying slower and more uncomfortable, but what we learn lasts longer. Something similar happens with what we generate ourselves. We remember it better than what we only read, even if our first attempt is wrong. Mind you, afterwards you have to check the correct answer. Otherwise, the mistake stays with us.

Beware of the illusion of competence. We read something, understand it effortlessly and think we already know it. Until the test comes and we can’t explain it. Rereading your notes feels productive, but almost never is.

In practice, this translates into three habits:

1. Get it wrong first. Before starting a topic, a class or a tutorial, try to answer without knowing. You’ll fail, and that’s what gives the theory the weight of an alarm bell.
2. Don’t reread, explain. After reading, close the material and explain what you understood in your own words, out loud, like you’d explain it to a five-year-old. Wherever you get stuck is the path to follow.
3. Answer before looking. When you test yourself, always write down what you think the answer is before seeing the correct one.

Learning should feel clumsy. Clumsier than doing it with your feet.

Using AI to learn

These practices take discipline, and discipline is hard when the answer is one message away. While AI can be what blocks us, it can also be the answer. An AI that answers takes the effort away from us, whereas an AI that asks gives it back.

We can learn from many sources or from a single tutor. Many sources give more perspectives, but they scatter our attention and force us to find material, organize it and verify it. An AI tutor can gather those perspectives and hand them to us in one place. That way the friction leaves the logistics of studying and stays where it belongs: in the moment of learning.

A cycle that works:

1. Diagnosis. Ask the agent to quiz you until it finds where what you know ends.
2. Material. With that, have it generate study material adjusted to your level: not so easy that you get bored, not so hard that you give up.
3. Test. Have it test you, and you answer before seeing the solution.
4. Repeat. If you fail, go back to the material. If you get it right, move on to the next topic.

This way we can use an agent as a private tutor and aim the difficulty at the right spot.

Closing

For centuries, learning hurt without anyone asking for it. Now the effort is optional and, like almost everything optional, it’s very easy to skip.

AI can give us all the answers. The hard part is asking it for the questions. So the next time you open a chat to understand something, do the counterintuitive thing: ask it to test you, get it wrong with confidence and explain the topic to it as if it were a five-year-old.

Let’s not outsource our critical thinking. And if learning feels clumsy, you’re doing fine.

Even so, the path to landing your first job still has the same steps as when I started. What changed is how you get evaluated.

How I got started

When I started, web development seemed like the safest option. I learned React and Node.js, because using the same language on the frontend and the backend made sense to me. I built the classic to-do lists and, since freeCodeCamp was all the rage, I jumped into the “365 days of code” challenge. There I put together a simple online store with HTML, CSS and JavaScript. It was pretty basic, but it helped me understand how the web works.

Back then I read a lot about how to get a job, and the advice was always the same:

1. Apply to everything you can.
2. Go to meetups and events to meet people.
3. Build projects that show what you know.

I was doing two out of three. I applied like crazy and practiced with React nonstop on side projects.

In the end the job showed up on my university’s Slack. Someone posted that they needed a Meteor developer, a framework that joined the backend and the frontend through methods. First came a technical test, and that’s where the projects paid off: it went well, I moved on to the interview and they saw that I was excited about the technology. I had never heard of Meteor, but knowing the fundamentals it wasn’t hard to adapt. It was just a matter of knowing how to write JavaScript. But this was more than 5 years ago.

What didn’t change

Today it’s still the same: you apply a lot and get rejected a lot. And having someone who recommends you is still what helps the most for the first job.

But something did change. I have classmates with six years of university who still can’t find a decent job in Chile, and it’s not because they don’t know their stuff.

What did change

When you apply, the first thing that checks your CV is how many years of experience you have with each technology. An ATS or a person. If the posting asks for three years of React and you don’t have them, you’re out. The problem is obvious: a junior has no years of experience, because nobody has given them their first job.

I don’t think it’s the recruiters’ fault. Finding out whether someone codes well takes time, so people filter by what’s easy to check: keywords and years. That leaves out precisely the people who are just starting. And with so many companies betting on AI instead of hiring, there’s even less room.

I think this will get better at some point. In the meantime, it makes sense to adjust how we present ourselves.

What I would do differently today

Tailor your CV to each posting. Your CV doesn’t have to tell everything you are. It has to get past the filter. Use the same words the posting uses and leave the rest for the interview. Sometimes I’ve even seen the recruiters themselves edit your CV so that it includes the technologies.

Prioritize referrals. If someone at the company recommends you, your CV goes straight to a person who understands what you do, without going through the years-of-experience filter. That’s why it’s worth investing time in getting to know people in the industry.

Build projects to learn, not to show off. Most likely nobody will look at your projects before calling you, so don’t stress about having a perfect profile. Projects are for learning and for walking into the technical interview relaxed, which is where someone who actually knows programming finally evaluates you. If you understand the fundamentals well, you can hold your own even if the posting asks for a technology you haven’t used.

To wrap up

The process is broken and we’re not going to fix it ourselves. What we can do is understand how it works and not take every rejection personally. Almost always it says more about the filter than about you.

Tailor your CV, find someone to recommend you and keep learning with your projects. There will be rejections and uncertainty, but that’s part of the process, not a sign that you’re not cut out for this.

Every day that passes, AI is more capable. I see how code agents are pushing junior developers out of the equation. In graphic design, generative tools package logos and illustrations in seconds, making the work evaporate slowly but surely. It’s a shadow relentlessly spreading over marketing, audiovisual production and, needless to say, translation.

But there’s a gap that still hasn’t been filled. We’re building systems that can understand language but not the purpose or value of what they say, at least not in a human way. Artificial Intelligence doesn’t achieve the perspective of will, and it can’t deal with the unknown except by hallucinating.

The illusion of will

In case you didn’t know yet, what we call AI these days is LLMs (large language models), systems that learned language patterns by reading an enormous amount of text. At an atomic level it started with the idea of predicting the next word.

Roses are …

Now, predicting the next word requires building a complex representation of the context. Building multiple contexts and relating them to each other in sophisticated ways. How this new word influences the whole conversation. Over time these models have grown in size, and so have their training sets, reaching capabilities that resemble reasoning, communication and problem solving.

And with that came people’s fear and anxiety. But these models don’t cover important aspects of our infrastructure as a society. Not all of our activities can be extrapolated into a training set.

Visualizing patterns, applying probabilities, finding sequences of tokens or words and statistical association is how models see the world. Experience, intent, responsibility, context and values are left to our side of the court.

Because every model categorically confuses frequency with truth, we forget that every dataset it is trained on has errors. That these models touched the internet. And the internet lies, right? Condemned to replicate and optimize the world as we describe it to them. With all the garbage and fiction, all the fanfiction, wattpad and absurd conspiracies. We have to tell the truth apart from the garbage it hands us and connect the wires to get on the right track, our track.

We went to A and then C, no problem getting to B. Now how do we get to Z

What is finite and easy to capture, the common events that feed these immense machines, shapes a perfect and efficient model of thought, 100 times more efficient at transactional tasks, where the details are so well defined that we could find a needle in a haystack.

But the world contains much more entropy than even we are willing to accept. It’s much messier and more chaotic. Strange events, atypical combinations or creative scenarios could leave a long tail that goes on to infinity. Or rather, they would have found the end, because they always do, but phenomenally wrong:

“Eat at least one small rock per day”… (BBC news story)

Also, in an imperfect environment like our reality, there’s another dimension that has to do with combinatorics: adding variables quickly leads to exponential combinations. For the way these models work to capture that dimensionality, we would need an enormous amount of data.

That’s why we should be careful with the illusion of having in front of us an image of ourselves, and its estimates. We still don’t have a model capable of “instant learning”. We won’t find any model that knows the art of improvising to get out of a jam.

RANT

What I wanted to say is that our work, and that of many others, will still be there: dealing with human ambiguity, battling legacy systems, struggling from one version to the next because someone decided to build on an unstable base. Designing discrete systems with an immense reality in mind.

There’s no machine that solves for us the problem of uncertainty, of long-term complexity. What does a code agent care whether the application is still working in a couple of years? The only thing that changes is that now we’re going to be buried under a mountain of code. And who is going to save us from that 80% of garbage code?

I hope you and I aren’t too lazy by the time there’s nobody left to hold accountable; when the concept of “AI first” has us digging through a cesspool that looks like it was written by an alien with attention deficit. And investors are going to love it, because it “was built in two days”. But who knows what the hell it summoned, and why it decided to import three libraries, cross dependencies and import half the internet.

The task and the goal was to be more productive, to be able to reach targets in impossible timeframes. To use modern technologies at a competitive pace without losing quality along the way, and without ceasing to build solid, scalable solutions. Do more with less. High cohesion and low coupling.

On top of that, for my part, there was the challenge of keeping the attitude of the craftsman, the blacksmith, even when industrial machinery is at hand. A task that turns into a paradox: how to see beyond what merely “works” thanks to sheer mass production and keep the passion for the craft. How to transfer this intrinsic concern for the work to a stochastic model.

First month

To resolve this paradox, in the first few weeks I had to learn in detail what I was dealing with. And maybe this is the best moment to get into the subject and tell you about Claude Code. A programming agent used through the terminal, which has access to different actions inside your computer.

At its core, “Claudito” works with the concept of context. Imagine a room with defined walls and square meters, where light comes in, along with the furniture, table and chairs, people and pets: like a finite space of information that gives meaning and limits to our reality. And this is important: you have to keep in mind the limitations and how many things fit in the room. The context must contain everything needed for the solutions Claude delivers to be valid and accurate. MCPs, for example (the tools or extended functions, for instance to simulate a browser or access Google Drive), take up a significant amount of space in your context, and can leave you without enough room to give the agent the key background of the problem, inevitably making it lose track of the solution.

I started using it with these concepts in mind, the way its own creators suggest. A sequence of explore - plan - code - commit, but as the weeks went by I felt I was repeating my own flows. So I looked for the other ways people were using this tool. And I discovered the concept of the harness and how to customize it.

Second month

The harness comes by default, and although it isn’t the most optimal for every problem or technology, it works. The agentic harness is defined as the set of tools, context management and execution environment that turns a language model into an agent.

In other words, it could be translated as the harness that holds a climber on the mountain. In climbing (unless it’s free solo), you need gear. Otherwise, you have nothing to hold on to; you have no protection. The harness is the safety equipment that connects you to the mountain. It gives you the ability to act, to be there and to move forward. And what better than having your own tools and adjusting them day by day.

Without this, the solution takes a bit longer, or you find yourself telling it the same things over and over. So, from the second month on, I added dedicated skills and commands for the patterns and technologies I use, taking inspiration from a repository (ECC, winner of Anthropic’s hackathon). All of this always implemented from a TDD (Test-Driven Development) perspective from day one. Tests here are vital, both to validate your code and to serve as a path for the models to understand it as the solution keeps growing. They are path and validation. Having the right patterns in every new plan secures my solution, but it isn’t free: there is a context and token cost attached to every plan. Although, in my opinion, it’s completely worth it.

And to make this harness work without running out of space, I leaned on persistent context, or memory. Since the session space is limited, per project you can have a CLAUDE.md file and various other .md files. These work as a usage guide; base instructions that Claude reads when starting inside a folder so it knows, beforehand, what the rules of your project are. The interplay between context and these files when working with Claudito also makes the difference.

In my opinion

With these techniques, Claude has become a snowball of productivity. It’s what it promises: things that once took me weeks now take me a couple of minutes. Analyses that might take me months, Claude solves in one well-run session with the right questions. It’s hard to look competitive in this industry without Claude as a copilot. Now, Claude doesn’t get distracted and doesn’t doubt. And it’s at your command like an army of one. Army of one.

I know I can still apply techniques to reduce token spend, and even use that crazy learning skill where Claude recognizes my workflows. I dream of the day when you just talk to the computer and interact with a machine of peculiar personality; as of today, this is the closest thing to what I once imagined. And I also know how different Claude is working on existing code and its tendency to create rather than maintain. That its way of maintaining is adding and adding code. That it has strong preferences and that if you get careless you end up creating a swarm. Its swarm, one you don’t understand. So my advice is to be careful and always keep understanding the moves toward the summit.

On the other hand, and with all that said, it’s hard to keep seeing myself as the craftsman forging the rings of power, devoted to one single, specific and spectacular task. The day-to-day shifted more toward that of a strategist, drawing routes and plans, swapping weapon types and pulling the king’s tokens as if it were war. Using the terminal and writing natural language to get what I want instead of flowing through logic gates.

Architecture today

For a while now, microservices seem to dominate everything, and with them, FastAPI in Python. The adoption of the cloud as infrastructure in almost every company points in that direction. However, the most obvious downside of this approach is managing and orchestrating those microservices; you have to be very careful with the dependencies between them so you don’t “cross the wires”. You need highly skilled people to keep these operations running.

That said, microservices have become the standard. Tools have emerged to make them easier to use, like containers, Kubernetes or Prometheus, and they offer a ton of advantages that can leave a technology like Django behind. It’s slow, or at least on the surface, whereas FastAPI is fast, both when processing requests and when developing with it. It also includes typing almost “for free” (something Python really benefits from, like JavaScript needed it) and has an extremely robust dependency system.

On the other hand, Django has been around since 2005; it’s almost as old as Facebook. It stays relevant thanks to a well-organized community that is passionate about web development. As a result, a large share of the usual problems of programming for the web are already thought through and solved. It comes with “batteries included”, a term that means a big part of your solution is ready from the start (authentication, admin panel, ORM, security, templates and routing). The problem is that its philosophy doesn’t align as well with this microservices trend, since it comes from an era when the monolith shined: the application as a centralized whole, with a server-side orientation.

Still, Django has important downsides. It looks slow and, back in the day, there was no way to make asynchronous calls (something that would seem crazy today). In terms of scalability it can fall behind, even with its modular monolith structure and per-app deployment. Also, Django has a strict, opinionated way of working. It can be overkill for small projects. All of this leads us to its learning curve, which is steeper than that of its alternative.

With that said, I’d like to dig deeper and analyze the different dimensions from the business perspective, which are what will ultimately lead us to decide between one tool or the other.

Time To Market

We need to be clear about the business priority when launching the MVP: What is the product about? Does it need to manage users, roles or some kind of common administration? Or, on the contrary, is the execution speed of each call in a specific service more important? These questions guide us. If the solution requires managing users, passwords, moderating content or having some kind of administrative support, with FastAPI you’ll have to build all of this from scratch and timelines will increase significantly.

On the other hand, if you need to stay in sync with frontend or mobile teams, FastAPI will give you the smoothness. Its interactive documentation and how quickly you can prototype routes ready for the frontend team to consume speed things up incredibly.

It’s also ideal for validating ideas and exploring markets with a very specific tech service. We’re talking about something so concise that Django’s robust infrastructure would only get in the way.

Budget and Team

With no team and no budget, Django shines. With very little, we can do a lot. And if you add AI agents on top of that… in the same codebase and practically natively. A single developer can handle a big solution, moving from the database all the way to the visualization and the interface.

However, we have to remember: jack of all trades, master of none.

The story changes if you have a structured development department, with at least one team dedicated purely to the frontend, several developers and the resources to invest the time it takes to “reinvent the wheel” again. Although, let’s be honest, it will be a much more specific and faster wheel. At the end of the day, if we’re competing in Formula 1, I wouldn’t recommend driving a pickup truck.

Product vision

Are we building a heavy, centralized platform, or a product that will be part of an ecosystem of services? If the business value lies in convoluted rules and in managing structured data, Django is most likely the right direction. On the other hand, if the value lies in processing speed, concurrency and independence, maybe it isn’t. You have to stop and think: how do I see this solution in 2 or 3 years? Things to keep in mind:

• Relational complexity
• Centralization
• Technical specialization
• Interface independence

Scalability

At first glance, this fight comes down to synchronous vs. asynchronous. FastAPI is async by default, and microservices grow much better than monoliths. However, in reality, giants like Instagram, Pinterest and Patreon started (and to a large extent still operate) with Django. Saying that Django can’t handle large numbers of users is simply not true.

The real question is: does that massive traffic happen at exactly the same moment? If the challenge goes beyond just “holding up” under more users and centers on real-time interaction between them (like a live chat or a multiplayer game), FastAPI is the right call so the architecture doesn’t wobble.

Agility

In these terms, a few years ago Django was an undisputed star; it saved us a lot of time by letting us do more with less code. Today, with AI agents spitting out code like machines, this “batteries included” feature loses a bit of weight. Now we can achieve the same thing using smaller tools.

However, Django has evolved and found a new niche of value: standardization and keeping chaos under control.

A less experienced engineer is much more likely to end up with a chaotic, incomprehensible codebase using a tool like FastAPI than using Django, since the latter tells you step by step how to structure things. Many frameworks do this (like Ruby on Rails or NestJS): they put up “guardrails” so you don’t go off the road. Writing code with AI means that today, more than ever, we have to care about maintainability and technical debt.

KISS

At the end of the day, to choose correctly we can narrow it down to knowing where we are, who we are and where we’re headed.

So, here, with a fridge, a couple of pieces of furniture and some kitchen stuff, this adventure begins.

I have to take the metro every day. The number of people is incredible. Rush hour gets packed with long faces, shoving and bad moods. But I get it, distances are much greater, and so are prices. Centralization. At least I have everything next door. If I want to shop, I have two Lider supermarkets a couple of minutes away. Are two Lider necessary? The truth is both are packed after 6 in the evening. There are also several pharmacies, bookstores, cafés, café chains, specialty coffee shops, small ones, big ones, themed ones, bad ones, good ones… The point is there are a lot of coffee shops. On top of that, there are restaurants and bars, a Domino’s that serves completos with the tomato on top, among many other stores of every kind with their own quirks, and there’s still a lot left to explore.

Job hunting in 2026

My job search was long. At one point I was torn between taking the full cloud path and going with AWS and its different specializations, since Python in the industry seemed like something forgotten or left to certain creatures hundreds of years old. But a hybrid worked: at its core it’s the ability to work with constant streams of data. Ensuring systems stay up and having the speech ready when it comes to interviews. Another decision was between on-site and remote. There, reality showed me how remote jobs have been disappearing. That pandemic-era industry no longer exists, it has been slowly dying out.

Worse still, a lot of the people who built their lives around remote work have had to go back to the offices. Imagine: a life built around that, the house, the kids’ school, transportation. Your whole spending flow changes completely between one way of working and the other. Because it’s obvious, a 20-minute trip is not the same as a 2-hour one. Having to take the metro or not. Having to share spaces or not. I think working on-site has its advantages, but I think a company that works remotely should keep betting on it.

Developing as I go

This post has been more on the reflective side. I hope to give my more technical opinion on things soon. I’d like to wrap up with an idea of what I think being a developer in 2026 is like. A lot to say, little to code. I think I spend more time talking to an agent and refining my instructions than defining patterns, classes or functions. More time paying down technical debt than leaving it behind. Understanding the domain and the business rules. Deciphering the intentions of other developers or PMs.

An industry that seems made for generalists, where anyone can program (wink, wink).

I spend most of my time translating logic between frontend, backend and infrastructure languages, and not deciding whether to use a frozenset or a tuple as a dictionary key. Specialized jobs probably still exist, I don’t know about in Chile. Even less so with the arrival of AI agents, something I plan to write about in another post, since this mess is already starting to look like Frankenstein.

Docker is a platform for developing, packaging and running containers. Important word: containers, which are isolated environments that include everything your software needs to work. These containers are created from images, immutable and reusable templates defined through a Dockerfile. Thanks to this, the same image can be used in development, testing and production, becoming a consistent unit of work in a distributed world.

There are also other concepts that tend to be overlooked: volumes, which let you persist data, and networks, which connect containers to each other. All of this within an ecosystem like Docker Hub, which offers thousands of ready-to-use images.

I think knowing that, you could already start working and integrating containers into your workflow. But we don’t stop here, let’s go a little further.

Before the whales

Before Docker there were virtual machines (VMs), which are, in essence, a complete emulation of a physical computer inside another one. Each VM acts as an independent machine, with its own virtual CPU, RAM and storage, which lets you run operating systems and applications in an isolated and secure way.

We could ask ourselves: why not keep using virtual machines? But there’s an architectural drawback: the weight and volume of the box exceed those of its contents; that is, the system is wasting resources.

Each instance has to load and run a full operating system (Ubuntu, Debian, Windows or another), which takes a lot of resources. VM disk images usually take up gigabytes, and the boot process can take several minutes, even for simple applications. This creates overhead that affects both performance and system efficiency.

Using the kernel

Containers, unlike VMs, don’t emulate a complete computer or require a separate operating system. Instead, they share the host operating system’s kernel and isolate only the processes and resources needed to run an application. It’s operating-system-level virtualization. This removes much of the overhead, allowing more efficient use of resources and near-instant deployment.

A good way to picture it is to imagine a VM as a detached house: it has its own foundations, pillars, electrical system and plumbing. Containers, on the other hand, are like apartments in a modern building. Each apartment shares the main structure, the electrical system and the plumbing. And yet each apartment has everything it needs to live comfortably and independently.

Thanks to this we get Docker’s key values, particularly efficiency and resource optimization versus virtual machines:

• Portability: it works everywhere.
• Efficiency and resource optimization: lots of containers.
• Isolation and standardization: unit of work.

Namespaces and cgroups

Containers work on top of the kernel in an isolated way through two mechanisms: namespaces and cgroups.

A namespace abstracts global system resources so that processes believe they have their own isolated instance. Changes made to a resource are visible only to the processes that belong to the same namespace, remaining invisible to the rest.

Currently, the Linux kernel has 8 types:

If namespaces decide what you can see, cgroups decide how much you can use.

Cgroups let you allocate system resources (CPU, memory, network bandwidth or a combination) among user-defined groups of tasks (processes). And they go further, letting you monitor the consumption of the configured groups, restrict access to certain resources or set limits. They even let us adjust limits and priorities dynamically. With these mechanisms we achieve isolation.

Docker operates on immutable layers

An immutable layer is a set of read-only files that records a specific state change in the image. Since they can’t be altered, Docker reuses them across multiple containers without duplicating disk space, guaranteeing that the environment is always identical and predictable (determinism). Any later modification doesn’t edit the base layer, but generates a new one on top of it, protecting the integrity of the original source.

Working across layers is possible thanks to the concept of UnionFS. This engine takes folders in different layers and “merges” them virtually so they look like a traditional filesystem. This way we get immutable layers working in harmony, making it possible to spin up disposable infrastructure that is completely replicable.

Communication and networking

The network namespace is what isolates the network. Each container operates as if it had its own network card and its own IP. Based on this, to connect containers we need a “switch”, a bridge that allows interaction, as if it were a physical network, creating virtual cabling through a subnet.

But there’s a problem: IPs are ephemeral and, so we don’t have to configure IPs all the time, the internal DNS server steps in, intercepting the request and returning the current IP, or rather the service name. These 3 mechanisms let us keep communication fast, secure and reliable.

Docker and its friends

However, Docker is just the unit of work. In modern professional applications (like those using Django or FastAPI), we rarely work with a single container; we usually need a database, a backend, a worker and a frontend working together. This is where Docker Compose comes in as the orchestra conductor. With a single configuration file, you can define a complete infrastructure for a digital product.

Other technologies like Kubernetes or Docker Swarm let us orchestrate at a larger scale.

With that, I think that’s enough whales for one day, maybe for a week, maybe for a good while. I hope it taught you something, and remember that all of these technologies draw heavily from others like operating systems, virtualization and networking… and remember: if you’re out there working with Docker, don’t forget to create your .dockerignore.

Note:

Docker Compose is great for development and testing, but in production you shouldn’t put the database in a container. A database needs real persistence, high availability and good performance tuning. For production, it’s safer to use managed services (AWS RDS, Cloud SQL) or dedicated VMs with backups, replicas and serious monitoring.

Resources

• How containers works
• Understanding image layers (Docker Docs)
• Layers of Docker image 101

For the last few weeks I’ve been mulling over how operations and concurrency work. What guarantees that a critical operation won’t break the system?

Transaction Fundamentals

Nothing. There is no configuration that’s right for every case. What does exist is understanding how transaction states behave when they work together. A transaction is a consistency contract. When we don’t understand what happens at the levels below, we leave the system’s integrity to chance.

This becomes obvious when we have to work on financial services, cryptocurrencies, inventory management, reservations or distributed systems.

ACID Transactions

When databases started being used in critical systems, failures left data in inconsistent states, causing costly errors. In the 80s, Jim Gray and other researchers defined the ACID properties: Atomicity, Consistency, Isolation and Durability. Four rules that guarantee that, even in the face of failures, data stays correct.

Atomicity

It’s the “all or nothing” idea. A transaction can have 10 steps, but if step 9 fails, the other 8 are undone as if they had never existed. This is achieved through logs (Write-Ahead Logging). The database writes down what it’s going to do before touching the actual data. If there’s an error, it uses that log to apply a Rollback and return to the initial state.

Consistency

It guarantees that a transaction only takes the database from one valid state to another. The core of this property is enforcing business rules. The tools involved are Triggers, Foreign Keys, Check Constraints and data types. For example. If you try to set a negative volume and there’s a rule forbidding it, the transaction bounces.

Isolation

This is where things get interesting. When several transactions try to access and modify the same resource at the same time, they can’t simply run in parallel without coordination. If they did, we’d end up with inconsistent states. That’s why a transaction has to wait its turn while another one finishes its operation on that same data.

Concurrency happens when the execution of two or more pieces of code behaves as if they were running at the same time.

To deal with concurrency, coordination is achieved with mutual exclusion primitives. At a low level we’re talking about mutexes: mechanisms that guarantee that only one thread or process accesses a critical resource at a time (if you want to know more). In databases, the concept translates into locks, which apply that exclusion on rows, pages or tables. It’s not optional cooperation; the engine enforces these rules to protect integrity.

Now then, when and how are these locks applied? That’s where isolation levels come in: settings that define how strict the database will be when applying locks between concurrent transactions. Each level makes different trade-offs between consistency and performance:

Durability

It’s the promise that, once the system tells you “OK, saved”, that information won’t be lost even if the power goes out or the server blows up right afterwards.

Changes are written to non-volatile storage (hard drive/SSD) and confirmed in the transaction log. Even after a catastrophic failure, on restart the database reads the log and finishes applying whatever was left pending.

Beyond ACID

Nowadays, these concepts are the foundation of relational databases. However, understanding this is just the first step. When you make the jump to modern architectures with microservices and NoSQL databases, the engine can no longer guarantee ACID across the whole system, because your data now lives on separate servers and the rules of the game change.

When distributing information, ACID’s rigidity is often traded for a more flexible approach that prioritizes the system never going down. We call this new paradigm BASE:

Going from ACID to BASE means accepting that your system will live with some temporary inconsistency in exchange for being incredibly fast and resilient to massive outages. At this point data integrity stops coming from the engine’s configuration and becomes design patterns you have to implement in code (like the Saga pattern or Two-Phase Commit) to tie up the loose ends.

But that… is a story for another post.

When I started, I was driven by an interest in video games, an affinity for math and the discovery of the magic that programming makes possible; financial security was also an incentive. At university, chasing the same goal alongside my classmates helped me keep going despite how exhausting the road was.

But passion naturally fades. Time doesn’t forgive, and our brain gets used to stimuli, reducing the emotional response and the joy we get from tasks that used to produce dopamine spikes. Stagnation also shows up: as our skills grow without the complexity growing, we fall into a technical boredom where work no longer demands the cognitive effort that used to be rewarding.

Facing software development without enjoying it isn’t just tedious, it’s a trap. Spending hours in front of the screen without a single line of code sparking any enthusiasm is a problem of work philosophy. Programming without those little shots of dopamine is simply unsustainable. We usually talk about requirements and quality attributes for our systems, but we forget that our own process has to be maintainable.

This career is a long haul. If moving forward is hard for you today, tomorrow it will be impossible; so look after your motivation with the same rigor you look after your code, and treat your passion with the same determination you use to try to master your favorite language.

The Blacksmith Mindset

To find motivation again, I had to resist the idea that it’s enough for things to simply “work”. Although my experience lets me be efficient, there’s a gap between the functional and the “perfect”, understood not as an unreachable goal, but as the willingness to look beyond the obvious solution: separating the patterns that make up the structure and exploring alternatives until I’m sure the path I chose is the right one. There’s a deep joy in this technical mastery; being an expert is also fun.

However, this craftsman’s view clashes with the fast-paced world we operate in. We live in a society (insert Joker image here) hungry for speed and results, full of deadlines, story points and product managers. We ourselves want to see those results fast and without frustration, but learning comes with frustration. To reach excellence, there must be room for introspection, concentration and analysis. We have to look for alternatives and embrace the frustration of learning, accepting that to be good at something I first have to be bad at it. Making mistakes isn’t avoidable, it’s part of experimenting, and we shouldn’t treat that time as wasted time.

That pressure for speed is what breaks the bond with our work. When nothing belongs to us and our work becomes something foreign, a disconnection appears that directly affects our mental health: that’s where excessive workloads, difficulty setting boundaries and the importance of learning to say no come in. There are many ways to lose the joy in what we do, which is why we can’t leave our motivation to chance.

Adopting a craftsman’s mindset is claiming a purpose of your own. When the environment doesn’t offer us a clear sense of meaning, our task is to find satisfaction in the doing itself, rediscovering that the value lies not only in the result, but in the quality of our attention. To dig deeper into this concept, I recommend reading authors who explore “deep work”, like Cal Newport in Deep Work, who argues that regaining our ability to concentrate is the ultimate act of resistance in this era.

In the end, reconciling the efficiency the market demands with the excellence we seek is the only way to make this career sustainable. It’s not just about writing code, but about how we inhabit the hours in front of the screen.