Of course, we talked about work. I am not saying it is a good idea to talk about work during a dinner with friends; I am just saying it is today’s reality, and that carries a lot of meaning, such as:

• What everyone is up to.

• How we use AI in our jobs.

• Uncertainty about where our profession is heading.

Clearly, the uncertainty point took up quite a bit of time.

Throughout the conversation, one of my friends asked:

Guys, with all this AI stuff, how do you interview people applying for a Software Engineer position?

In today’s email, I will tell you what my current approach is for interviewing candidates in the early AI Native era. Specifically:

• Live coding test: yes or no?

• Using AI for the technical test.

• What gives me the most value in identifying a good candidate in the era of AI.

If you are a Software Engineer or Tech Lead involved in designing and running job interviews to hire Software Engineers, this email is for you.

Know someone who might be interested in this topic? Forward them the email 👇🏻

Share

Now, let’s get down to business.

Live coding test: yes or no?

This was the first thing that came up in the conversation, and I personally have a strong opinion on it.

In my opinion, live coding tests are dead. In fact, they were already dead before the arrival of AI, at least for senior profiles.

Why?

Nowadays, coding tests do not bring enough value to invest the time of two Software Engineers during a live interview with another person, since we have machines (Claude Code, Cursor) to generate code.

👉🏼 In 2027, code is going to be much less important than it is today. Things like design patterns, software architecture (MVC, hexagonal, etc.) will take a back seat, overtaken by other aspects such as:

• Code efficiency. AI code works, but is it optimal in terms of performance?

• AI-optimized code. A lot of code means a lot of tokens and a lot of money spent; this is something you know perfectly well today. Therefore, the code generated by AI in 2027 must be optimal from the start, so that the cost of creating it is optimal and its subsequent modification by the AI is cost-optimal as well.

For junior profiles, I still see some value in it, but not so much to know if they understand the language syntax, but rather to understand how their mind works when programming, whether they use patterns, and what tradeoffs they evaluate.

At this point, you might be wondering:

So, do I ask the candidates to use AI live?

Using AI for the technical test

There could be an alternative to the live coding session, but one that is more AI Native: live code creation but using AI.

☝🏼 However, this variant has certain challenges that I consider a blocker today:

• To program with AI, you need a paid account. Obviously, a company cannot expect candidates to pay out of pocket to spend tokens programming with AI for a live interview. In that case, how is AI usage managed?

• Waiting times for the machine to do its job. From the moment the developer asks the AI for something until the result appears, time passes; dead time that can lead to awkward silences and, worse, a waste of time for both interviewers and the interviewee.

As I said at the beginning, I think these are barriers that can make an interview even more difficult.

👉🏼 Instead, I think you can ask the interviewee about how they use AI today, and their opinion on using AI for code generation.

Why?

Because it will give you clues as to:

• Do they have the experience your company needs regarding AI usage?

• Do they fit your company’s stance on those aspects?

So, what can give me value in a face-to-face interview?

What gives me the most value to identify a good candidate in the era of AI

Two key aspects.

1. Cultural fit

You need to make sure the candidate is a cultural fit for your company. If the person is not aligned on:

• Values

• Goals

• Growth expectations

• ...

You are going to waste your time, you will fail at your goals, and the company’s reputation will suffer.

I won’t expand much more on this topic, as you can find interesting articles about it in this same newsletter.

• Ensuring to hire the right person

• The dilemma of the person with willingness but lack of experience

2. System design

☝🏼 This seems key to me today.

More than ever, you need candidates to have the ability to think about:

• The system.

• Dependencies.

• Global architecture.

• Making decisions based on trade-offs.

• The product to be built.

The largest part of your interview should revolve around system design.

If you are interested in learning System Design, I don’t have much about it in my newsletter, but I can recommend:

✨ Takeaways

So, what to keep in mind:

• Live coding is obsolete for seniors: Spending the engineering hours of two interviewers to watch a candidate write lines of code is a poor use of resources. In the era of Claude Code and Cursor, standard code generation is a solved problem (kind of).

• The problem with live AI testing: Running live coding sessions with AI introduces friction, such as managing paid tool licenses for candidates and dealing with awkward, time-wasting lag while waiting for AI outputs.

• The interview sweet spot (System Design & Culture): The true signal of a great candidate in an AI-native world lies in their architectural thinking and cultural alignment. Shift your interview focus toward global architecture, dependency management, making trade-offs, and ensuring core values match your team’s vision.

Now it’s my favourite part. What are you doing in terms of hiring? What are your approaches in this early AI Native era? Looking forward to your comments!

And then fail because they didn’t understand the business they were building.

In today’s issue, I want to share why understanding the domain is one of the most important skills in software architecture, especially when building distributed systems, and even in the era of AI code generation.

Most architectural problems don’t start with technology but with a misunderstanding of the business.

Have you ever felt like everyone on your team speaks a different language when designing a system?

In today’s issue, I want to share a small conceptual correction that will save us major headaches when designing distributed systems, because we often mix apples and oranges when talking about architecture.

What a Domain is NOT

When a team starts building software, it’s common to find purely technical divisions like a user service, a database service, or an email service.

But the domain has nothing to do with Java, Python, PostgreSQL, or Kafka. All of those are simply technological decisions.

☝🏼 The domain exists even if there is no software; if we turned off all of an airline’s servers tomorrow, the concepts of ‘Booking’, ‘Flight’, and ‘Overbooking’ would still exist in their business.

So, What Exactly Is a Domain?

According to Eric Evans in Domain-Driven Design (DDD)

The domain is the sphere of knowledge or activity—specifically, the problem area that the user is trying to solve with the program.

👉🏼 The domain is the problem we are trying to model, not the technical solution or the database.

A large domain (like E-commerce) is divided into specialized areas with their own rules, which DDD calls Subdomains:

• Catalog and Inventory

• Ordering and Billing

• Logistics and Customer Service

Bounded Context: The Boundary of Your Model

If you ask around your company what a “Customer” is, for billing, it will be a legal entity that pays, and for support, it will be a user opening tickets. Both are right.

That’s why we need a Bounded Context, which is the explicit boundary within which a business model has a precise and consistent meaning.

Mixing these boundaries without clear borders is the reason why software in large systems becomes fragile, error-prone, and extremely difficult to understand.

At this point, you may ask:

Why this matters in Distributed Systems?

In distributed projects, you don’t just divide code; you also divide responsibility, data, and communication between autonomous teams (Conway’s Law).

The classic mistake is creating services based on database tables (`UserService`, `ProductService`), which leads to cascading calls and a distributed monolith.

👉🏼 DDD proposes looking for business boundaries instead of arbitrary technical frontiers; therefore, a microservice should naturally map to a Bounded Context.

Protecting the Domain: Hexagonal, Clean, and SOLID

Once you identify your business boundaries, you need tools to protect that core from external contamination:

• Hexagonal and Clean Architecture: They ensure that the core business rules remain independent of the UI, frameworks, and databases using adapters. The domain doesn’t know what REST or AWS is.

• SOLID Principles: They don’t define the domain, but they provide discipline at the module and class level so that the business logic doesn’t get contaminated with technical details of SQL or protocols.

You have explanations about what a Domain is. Let's wrap up for today.

✨ Takeaways

Keep this in mind:

• The domain is the business: The software structure must reflect the business problem, not the chosen technology.

• Poorly defined boundaries = Chaos: The main consequence of not understanding the domain is drawing the wrong borders, causing coupling and architectural debt.

• Isolation tools: DDD is used to model complex domains; Clean, Hexagonal, and SOLID are the shields that prevent technology from muddying that model.

If I had to summarize everything in a single sentence, it would be this:

The structure of your software should reflect the structure of your business, not the structure of your technology.

Understand the domain first. The technology decisions become much easier afterward.

Write it in the comments, I read and reply to all!

If you're a software developer overwhelmed by the increasing number of pull requests to review as AI agents accelerate development, this email is for you.

The problem you have

Let me tell you where you are:

• You and your team adopted AI for development, using Claude Code, Cursor, or GitHub Copilot.

• You clearly see a positive impact; you and your team are able to do more work in less time. You don’t visit Stack Overflow anymore.

• And you want to keep “human in the loop”, meaning, you review all the pull requests opened. Yes, you caught AI in the act for some bugs already! So you have still to pay attention to what goes to production.

What’s your problem? You have many more pull requests to review.

And not only that.

Those pull requests are quite big. Maybe the same size as when your peers coded without AI, but now it’s different.

Before, you had:

And now you have:

👉🏼 In summary, you have more pull requests than ever, and they’re too large to review efficiently.

Does this ring a bell to you? I would love to hear about your experiences with this. Send me an email or drop a comment in Substack.

📧 Let me tell you a story

You are not alone, though. This is becoming a pattern in tech companies during the transition to AI Native.

Many people shared with me on social media how much they're struggling with this challenge. The growing volume of code reviews is consuming more and more of their time. Some sentences that I can write here are:

AI is a code-vomiting machine.

Another sentence:

The machine’s goal is to spend tokens and tokens, so you get code and more code.

👉🏼 The code review phase has become the bottleneck, when before it was the implementation or Product Management.

☝🏼 Is this true? In my opinion, yes, it is true.

You may ask:

Marcos, are we doomed to only do code reviews?

I don’t think so, at least, so far. It took me a while, but I found a way to:

1. Keep the human in the loop for code reviews,

2. And keep the increasing speed of development thanks to AI.

The solution

In a nutshell:

1. Use SKILLs so the agent works with SOLID principles, eventhough your previous code does not follow those.

2. Demand to your agent keep small pull requests, even though they are many. Ensure the agent saves that in its memory.

3. Demand to your agent to write an ADR/code-change-report for the pull request.

Now, let me elaborate on each item.

☝🏼 About the SKILL. You can rather try some from the Internet, like skills.sh, either create your own, or just add that requirement in your prompt.

Why I found this important? Because with that in its memory, the agent tends to create more organized and encapsulated code (which is a benefit of SOLID) and so it will make your code review easier to follow up.

📖 A pro-tip on this: Always start the the plan mode of your favourite AI agent. That helps you to understand what the AI agent will do and what will not do. Always iterate, do not go with the first plan provided; ask questions, so you can understand if the requirements are satisfied, and ensure you understand what will happen in the change.

✌🏼About the small pull requests. The AI tends to generate many code but, you have to rememeber this: the AI agent is there to do what you ask. Yeah, I know, sometime it does not listen properly, and you have to insist. You can ask to split a task in multiple pull requests and, my recommendation is that you explain to the agent why you want it that way: to make the code reviews of the humans more easy.

Why I found this important? As I mentioned before: small pull requests can be reviewed with more love and faster; the process becomes more efficient and effective.

📖 A pro-tip on this: Use the same human to review all the pull requests. Avoid the context switching for your peers, by rotating the responsibility of reviewing the code of your 5 pull requests, so only one person gets into it, making her/his review easier.

🖖🏼 About the ADR/code-change-report. The idea is quite simple:

• Humans read natural language better than code, no matter how expert you are in a concrete language.

• So, having a meaningful text that can help us to understand what has been done, will help us to achieve a better code review.

Maybe the word ADR is too much for a pull request, but I hope you get the point.

If you can ask your peers to keep small pull request, to can for sure demand that to your AI agent.

If you want to go deeper on this, I suggest you to read this post here entitled Code Reviews in the AI ​​Native era.

📖 A pro-tip on this: To achieve this, Wether on the pull request description or in a separated file (HTML, Markdown), you must ask the AI agent to create a:

Summary of the work so the developer to perform the code review can easly understand the changes in the pull request, highligting the important parts to pay extra attention.

Those three points helped me, and so I hope they will help you, to have more efficient and effective code reviews, keeping the pace of more pull requests and ensuring the right quality for the human-in-the-loop code reviews.

Beyond those three points, another practice that helped me was following the I.N.V.E.S.T. principle and taking the time to write clear and small Jira tickets (or whatever tool you use to organize your work).

✨ Takeaways

We started this email saying:

The code review phase has become the bottleneck.

With the solution I brought to you, we are making (yet another) shift left:

We are putting more effort on the previous work with the AI, during the plan of the work to do, before open the pull request.

👉🏼 Because the effort now goes more on the plan phase, you are making the whole process more scalable.

At this point in time, I believe this the way to work with AI agents.

I would love to hear the tips and tricks you use so far to tame the AI agents. Send me an email to write a comment; I read them all!

Best,
Marcos

In today’s issue, I want to share with you one of my failures in communication and how I overcame it.

If you’ve been following me for a while, you’ve already heard a lot about this. I’m not just repeating myself; I’m providing more resources to help you improve the key skill (communication) every Software Engineer needs, especially in the age of Agentic AI.

Three mistakes:

• Reuse the same diagram.

• Focusing on feelings instead of data.

• What to do when the conversation is about bananas?

☝🏼 By the way, this is a concrete example from real life.

Reuse the same diagram

I think this was my main mistake by far.

I had a meeting with the Product team to explain our approach to the roadmap’s requirements and use cases. To support the discussion, I used the same system diagram I use with my fellow engineers, people who have deep technical knowledge and don’t get lost in the moving pieces.

Consequently, the Product team felt the need to clarify every single component in the diagram. This was a natural reaction; they wanted to contribute to the solution and needed to understand what they were looking at. However, we ended up getting bogged down in the details and missed the main objective of the meeting.

👉🏼 To pivot from my mistake, it would be better to use visuals tailored to your audience and keep only what is relevant to the discussion. Otherwise, we risk creating noise, like debating AWS SNS data formats, instead of staying focused on the meeting’s goal.

Focusing on feelings instead of data

Another mistake I used to make was the usage of feelings and memories during the meeting, instead of numbers. This happened to me as well in the example I’m using today.

I went to the meeting with the right preparation. Because of that, I had to start using my brain to make it speak in a way that my audience could understand what I wanted to transmit; This is the basis of communication indeed, and it’s good, but not enough, because you can commit mistakes or forget things properly, and your audience can find a flaw in your speech.

Forget about what you remember in the past. Show data, show numbers! Prepare your meeting to showcase numeric information, with dates, rates, or whatever applies to your use case.

👉🏼 It’s better when you use information that your audience can read and understand by themselves.

What to do when the conversation is about bananas?

This could happen, and it happened.

I found myself having to explain to the Product team why we were using a specific data format for the messages passing through AWS SNS. I can tell you that’s not what I wanted to talk about. At that point in the meeting, it felt like it was too late to try to steer the conversation back to the original topic.

👉🏼 My recommendation at this point is to try to end the meeting, wrap up, and call for another meeting (yeah, I know).

You have to make your audience understand that you need to go through all the points discussed to adapt your solution.

For that, you will invest the time until the new meeting to adapt your visuals and your speech, based on the points discussed above, and remove from the table parts that match with:

1. Bring noise to the conversations.

2. Make the system complex to understand.

3. Not useful for the goal of the meeting.

In order to know if something matches those 3 points, I ask myself: Will my audience ask for “this” that is not relevant to my goal? If yes, drop it.

From here, you will create layered diagrams and speeches, each of which is focused on a different audience you will meet to achieve your goal.

At this stage, you ask the following:

Marcos, what do I mean by layered resources?

I mean that, from the raw and complete information about the topic to discuss, create visuals and speeches for each of the personas/audiences you are targeting.

📖 For example

• For your dev teammates, create visuals and text descriptions that make it pretty clear how your system works, so they do not get surprised when they find “that missing Lambda function there”.

• In the case of your Engineer Manager, maybe you have to scale up +1 level of abstraction. Maybe she/he does not need to know all the possible Kafka topics or microservices in place, but a diagram where is displayed the technologies used, the changes to be done, and the risks.

• Thinking about your Product Manager, definitely, she/he does not need to know if we are using AWS Lambdas or SNS or whatever. Use plain boxes without naming technologies and arrows to join the pieces and showcase the flow.

Keep in mind the visual I gave you in the section “Reuse the same diagram“.

👉🏼 You should go from super-low level to higher layers of abstraction, each of them meant for every kind of persona.

Let’s finish for today.

✨ Takeaways

Always take the time to prepare for your meetings by tailoring them to the specific audience.

It’s easy to let this slip through the cracks, especially when you’re caught up in a high-speed environment and focused on your daily routine. If it happens to you, don’t sweat it. Just schedule another sync to buy yourself some time, go over the main points again, and pivot your presentation to match their level.

In concrete terms, keep this in mind:

• Do not use the same visuals or the same speech to explain a concept to different roles.

• Use layered resources for the different kinds of audiences.

Hope you enjoyed today's email. I would love to hear from you about what are your experiences communicating. Drop me a message, I read them all!

Marcos, we are a 5-person startup, and it’s time to scale up our organization… because the money came in!

First, I said:

Congratulations!

Second, it was about working together on a proposal to scale up their organization.

We worked together in a couple of sessions, and she ended up with a growing plan that makes sense, based on their roadmap.

At some point, she told me:

Marcos, this is gold… this can help many people.

So, a tic happened: Why not provide the very same resources, already organized, to my readers?

In today’s email, I’m sharing a list of resources to help you create a growth plan for your engineering organization, whether you are a 5-person start-up or beyond.

In this email, I will add the links. If you are interested in this topic, I could write a detailed series for it. You tell me 👇🏻

I have 2 major categories for you to go through:

• Reading Content: Content you can read in this newsletter, organized by order

• Video Content: The talks I’ve performed about company growth, which include lessons learned.

Reading Content

• Ensuring to hire the right person

• Do you need a Rockstar developer?

• The dilemma of the person with willingness but lack of experience

• Hiring for an Hypergrowth company

• Hiring going into Hyper Growth - HR

• Hiring going into Hyper Growth - Engineering

• Onboarding Junior profiles in Hyper-growth

Video Content

• [English] Lessons learned hiring as a teamwork - Marcos Fermín Lobo e Inma Jimenez Garcia - DevOpsDays Madrid

• [English] From Cloud Native to AI Native or [Spanish] De Cloud Native a AI Native

• [Spanish] Lecciones aprendidas trabajando en una empresa Unicornio en modo hyper-crecimiento

I want to specially thanks to Jose Emilio Labra, who gave me this amazing opportunity to share my experiences with the students.

Now, let’s jump into it.

When I started my career, I believed that professional growth was a simple matter of time. I thought that after about five years of cranking out code, someone in the company would magically come to pat me on the back and say:

Marcos, we’re going to promote you; it’s your time to lead.

Fortunately, I realized that the real world doesn’t work like that at all.

In today’s issue, I want to share my most sincere experience on how you actually grow and build a career in a tech product company. We will cover:

• The myth of automatic promotion and the two main career paths.

• The radical importance of openness to change.

• Why you must act like the role you want before you get it.

• The vital need to make your work visible to management.

If you’re aiming for a promotion and want to understand how things really work behind the scenes, this edition is for you.

The Myth of Automatic Promotion and the Two Paths

As I was saying, growth in the tech industry has nothing to do with the time you spend warming a chair. In the past, it seemed like the only natural destination for an experienced developer was to become a manager, whether you liked leading people or not.

Luckily, that has changed. Today, you have two main paths to scale:

• The Technical Track (Individual Contributor): This is your path if your passion is to stay close to the code and architecture. You evolve into high-impact roles like Tech Lead, Staff Engineer, or higher, where your focus is on solving strategic architectural challenges without involving yourself in the hierarchical management of people.

• The Management Track (Engineering Manager): Your responsibility shifts. Your core focus is no longer coding, but genuinely caring about the career development of your engineers, aligning product goals, and ensuring your team has what it needs to perform at its best. It’s a different mindset.

Attitude is Everything: Openness to Change

If you just graduated or even if you are already a Senior, there is something fundamental you must internalize: openness to change.

In job interviews, it is assumed that you have a solid programming foundation. What truly sets you apart is your reaction when asked:

I know you master Java, but if the project requires it, would you be willing to code in Rust?

People who show open-mindedness:

yes, I will learn whatever is necessary.

These are precisely those who end up making huge leaps in their careers.

Act Like the Role You Aspire To

I’m going to be direct:

👉🏼 No one is going to come out of nowhere to say:

we’re promoting you,

So then you start acquiring responsibilities.

Especially from Senior roles onwards, you must act like the role you want to obtain before it is officially granted to you.

☝🏼 You must proactively demonstrate that you are capable of making design decisions, arguing at a technical level, and leading de facto. It is the only way to make it clear that the position already belongs to you morally.

Make Your Work Visible

This is, by far, the point where we technical profiles fail the most. I know, for those reading this newsletter, this already sounds familiar to you.

Still.

In an early-stage startup, it’s easy for your manager to see the quality of your work directly. But when the organization scales, your Engineering Manager will be swamped with obligations; they will no longer have eyes to see the daily grind of the whole team.

👉🏼 You have to make it noticeable. It depends exclusively on you.

Strategically leverage your 1-on-1s or your evaluations. Don’t improvise; bring data. Show charts: Look at how the number of bugs in production has dropped since I implemented my initiative,” or “I’ve managed to reduce our infrastructure cost by 12%.” If you don’t value your own effort, no one else is going to come to tell management how great you’ve done.

✨ Takeaways

Let’s wrap up. Load these concepts into your backpack:

• Growth is measured by impact, not years: Seniority does not guarantee promotions.

• Choose your path: Decide if you provide more value solving technical challenges (Individual Contributor track) or empowering other people (Engineering Manager track).

• Embrace flexibility: Your adaptability to new ecosystems is your main competitive advantage.

• Act in the role before you have the title: Lead at the level of the position you want to prove you are ready.

• Visibility is vital: Document, quantify your successes, and proactively present them to your manager in your 1-on-1s.

I hope this edition has given you the focus you need to boost your next professional step with energy. Do you have something to share about it? drop me a message!

Long time since I brought you fresh ideas from other experts from real life, and I come once again with a special guest . I let Julia introduce herself.

Julia is a Senior Localization Engineer at McAfee and the founder of Black Ice (black-ice.ai), a semantic governance platform built for multilingual AI pipelines. With a background in Siri localization at Apple and certification as a sworn translator, she brings a rare mix of linguistic depth and engineering to the question of how meaning travels across languages at scale. She writes The AI-Ready Localizer on Substack for localization professionals, engineers, and product teams navigating the shift to AI-assisted workflows.

Julia gave me an account to give a try at her Black-Ice.ai product, and I can tell it’s really cool, really good user experience, and it’s already cracking!

I want to recommend Julia’s newsletter to all those Engineers, Product Managers, and UI Platform leads who are working on localization challenges.

The AI-Ready Localizer

The AI-Ready Localizer explores how multilingual ontologies, market intelligence, and data governance transform localization from translation into AI-powered, intent-driven global growth.

By Julia | Taking you global

I must confess that I’m really excited about what Julia brings to you. I already read it in advance and found it super useful, to the point that I want to apply it in my Engineering Organization.

If you’re building a SaaS product, you likely have multi-language support. This post is for you, so you don't f*ck up and show 'Hola' to Japanese readers.

Without taking any more time, I hand over to Julia.

Somewhere in your codebase right now, there is a hardcoded string.

Maybe it’s an error message added at 6pm on a Thursday. Maybe it’s a toast notification someone copy-pasted and forgot to wrap. Maybe it’s a button label that’s been there since the MVP and nobody has touched it because it works.

It will ship to your French users as English. And nobody will catch it, because your CI pipeline has no idea it exists.

This is the problem. Let’s talk about how to fix it structurally, not by asking developers to be more careful, but by making the pipeline do the work.

What i18n scanning actually is

i18n scanning is static analysis for your translatable content. The same way a linter catches an undeclared variable or a type checker catches a mismatched return type, an i18n scanner catches:

• Strings rendered directly to the UI without going through a translation function

• Translation keys referenced in code that don’t exist in any locale file

• Translation keys present in locale files that are never referenced in code (dead strings)

• Locale files missing keys that exist in the source language (incomplete translations)

• Strings built by concatenation that are structurally untranslatable

• Plural forms handled incorrectly — or not handled at all

None of these require running the application. They are all detectable from static analysis of your source files and your translation resources. Which means they all belong in CI.

The four failure categories you will actually encounter

Before talking about tools, it helps to be precise about what you’re scanning for. These are the categories that cause real production issues.

1. The hardcoded string

// This will never be translated.
// Your German users will see "No results found" regardless of their locale.
function EmptyState() {
  return <p>No results found</p>
}

// This will be translated, because it goes through the i18n function.
function EmptyState() {
  return <p>{t('search.empty_state')}</p>
}

This is the most common failure and the easiest to catch. A scanner walks your JSX/TSX, finds string literals being rendered directly as text content or passed as props like label= or placeholder=, and flags them.

The tricky cases are strings that aren’t visually obvious: error messages thrown in catch blocks, strings constructed in utility functions far from any component, aria-label attributes, document titles set imperatively with document.title.

2. The untranslatable concatenation

// Looks fine. Completely untranslatable.
const label = "Hello, " + user.name + ". You have " + count + " messages.";

// The problem: word order is not universal.
// Japanese puts the subject last. Arabic has six plural forms.
// Hungarian uses postpositions, not prepositions.
// You cannot translate the fragments independently.

// Correct approach: ICU MessageFormat
const label = t('greeting', { name: user.name, count: count });
// en.json: "greeting": "Hello, {name}. You have {count, plural, one {# message} other {# messages}}."
// ja.json: "greeting": "{name}さん、{count}件のメッセージがあります。"

This is harder to catch automatically because you need to identify strings being concatenated and then rendered, not just any string operation. But AST-based tools can detect the pattern. The signal you’re looking for is: a template literal or string concatenation appearing inside JSX render output or passed to a translation function as a dynamic argument.

3. Key drift

// Code references this key:
t('user.profile.save_button')

// But your en.json has:
{
  "user": {
    "profile": {
      "saveButton": "Save changes"   // camelCase, not snake_case
    }
  }
}

// Result: silent fallback to the key string itself.
// Your button now reads "user.profile.save_button" in production.
// This has happened to everyone. Usually noticed by a user, not a developer.

Key drift happens when code and locale files evolve independently. A rename in one place without the other. A key added during development but never put into the JSON. This should be a hard CI failure — a missing key is a broken string in production.

4. Incomplete locale files

// en.json — your source of truth
{
  "onboarding.step1.title": "Let's get started",
  "onboarding.step1.body": "Tell us about yourself",
  "onboarding.step2.title": "Set up your workspace"   // ← new key, added last sprint
}

// fr.json — what went to translators two sprints ago
{
  "onboarding.step1.title": "Commençons",
  "onboarding.step1.body": "Parlez-nous de vous"
  // onboarding.step2.title is missing
  // Your French users see English here. Or nothing, depending on your fallback config.
}

This is the most common failure in fast-moving products. New strings ship to production in the source language while translations are in progress. Whether this is acceptable depends on your release strategy, but it should always be visible — a metric, a check, a warning. Not a silent gap.

The tools

There are two broad categories: linters that analyse your source code, and validators that analyse your translation resource files. You need both.

For source code analysis (catching hardcoded strings and bad patterns)

• eslint-plugin-i18n-json and eslint-plugin-i18next are the most widely used for i18next-based projects. They flag untranslated string literals in JSX, missing translation function wrappers, and some concatenation patterns.

• @formatjs/eslint-plugin-formatjs does the same for react-intl/formatjs, with additional checks specific to ICU MessageFormat syntax.

• Custom ESLint rules via AST are often necessary for project-specific patterns — for example, strings passed to third-party component props that your off-the-shelf plugin doesn’t know about.

The thing to accept early: no scanner catches everything. They catch the patterns they were written to recognise. Your job is to configure them to match your actual codebase patterns, not to expect full coverage out of the box.

For translation resource validation (catching key drift and incomplete locales)

• i18next-scanner extracts keys referenced in your source and compares them against your locale files. It can output a report of missing keys, unused keys, and coverage per locale.

• @formatjs/cli does key extraction and can enforce that all extracted keys are present in your message files.

• A simple custom script — walk the locale files, compare key sets, output diff — is often worth writing for your specific structure, because your project’s locale file layout is probably not exactly what any off-the-shelf tool expects.

What the pipeline actually looks like

Here is a practical CI pipeline structure. Not every team needs all of this on day one, but this is the shape of a mature setup.

PR opened / push to branch
         │
         ▼
┌─────────────────────────────┐
│  Stage 1: Lint (fast, < 30s) │
│                             │
│  eslint i18n rules          │
│  → fail on hardcoded strings│
│  → fail on bad concat       │
│  → fail on invalid ICU      │
└──────────────┬──────────────┘
               │ pass
               ▼
┌─────────────────────────────┐
│  Stage 2: Key validation    │
│                             │
│  Extract keys from source   │
│  Compare against en.json    │
│  → fail on missing keys     │
│  → warn on unused keys      │
└──────────────┬──────────────┘
               │ pass
               ▼
┌─────────────────────────────┐
│  Stage 3: Coverage report   │
│                             │
│  Compare en.json vs         │
│  all other locale files     │
│  → fail if coverage < N%    │
│  → post coverage table      │
│    as PR comment            │
└──────────────┬──────────────┘
               │ pass
               ▼
┌─────────────────────────────┐
│  Stage 4: Sync to TMS       │
│  (on merge to main only)    │
│                             │
│  Push new/changed source    │
│  strings to translation     │
│  management system via API  │
└─────────────────────────────┘

A few things worth highlighting in this structure:

Stage 1 and Stage 2 should be hard failures. A hardcoded string is a broken feature for non-English users. A missing key renders as the key name in production. These are bugs, not warnings.

Stage 3 should be configurable by locale. You might tolerate 80% coverage for a language you recently launched and 100% for your primary markets. The important thing is that the gap is visible and tracked, not silent.

Stage 4 is where the pipeline connects to your translation workflow. Most mature TMS platforms have APIs and CI integrations. The pattern is: on merge to main, push new source strings to the TMS; the TMS notifies translators; translated strings are pulled back on a schedule or via webhook before the next release. The pipeline doesn’t block on this — it triggers it.

The pre-commit layer (before CI even runs)

CI catches things before they merge. Pre-commit hooks catch things before they’re even pushed, which is faster feedback and less noise in PR reviews.

Using lint-staged with your i18n ESLint rules, you can run string checks only on files changed in the current commit — keeping it fast enough that developers don’t disable it.

// .lintstagedrc
{
  "*.{js,jsx,ts,tsx}": [
    "eslint --rule 'i18next/no-literal-string: error' --no-eslintrc"
  ]
}

The rule of thumb: everything that can be caught locally should be caught locally. CI is the safety net, not the primary feedback loop.

The one failure nobody talks about: the source string itself

All of the above assumes your English source strings are well-formed and translatable. Often, they aren’t.

// This string will reach your translators exactly like this.
t('save_confirmation', { defaultValue: "Changes saved! 🎉" })

// Problems:
// 1. The emoji may render incorrectly or be culturally inappropriate in some locales.
// 2. "Changes saved" is ambiguous — saved where? As in rescued, or persisted?
// 3. No context about where this appears, what triggered it, or what "changes" means.

A scanner cannot catch these problems. But a string linting step on the source values themselves can catch some of them:

• Emoji in UI strings (flag for review)

• Strings over a length threshold that will break UI in text-expansion languages (German expands ~30%, Finnish can expand ~60%)

• Strings with no translation context/comment attached

• Strings that appear to be sentences but end without punctuation (or vice versa — inconsistent punctuation is a translation signal that something is wrong)

This is the layer most teams never build. It’s also the layer that most directly improves translation quality — because it improves the source before anyone translates it.

Where things break down even with a good pipeline

Having the tooling is not the same as the tooling working. A few failure modes that survive even well-structured pipelines:

The coverage threshold that never moves

Teams set a coverage gate at 80%, ship, and never revisit it. The threshold stops being a quality signal and starts being a number the pipeline checks so everyone can feel fine. Review your thresholds per locale, per quarter.

The scanner that never covers your whole codebase

ESLint i18n rules are easy to configure for your main app code. They are less often configured for your component library, your internal tooling, your admin panel, your email templates. Each of these is a separate surface with its own untranslated strings. Map your surfaces before you assume you’re covered.

The TMS sync that runs but nobody checks

Strings push to the TMS, but the translation workflow on the other side is not set up to handle them promptly. New strings sit untranslated for weeks. By the time translations come back, the feature has been live in English-only for two release cycles.

The pipeline does not fix a broken translation workflow. It just makes the handoff cleaner. The workflow itself needs ownership.

Key naming that carries no meaning

// This is the key you'll be debugging in eighteen months:
t('label_47')

// This is the key that communicates intent to translators and future engineers:
t('checkout.order_summary.total_price_label')

No scanner enforces key naming conventions, but your CI can. A custom ESLint rule that validates key format against a regex is ten lines of code and saves significant cognitive overhead over time.

Final thoughts: language is a build artifact

Here is the mental model shift that makes all of this click.

Your translation files are build artifacts. Like your compiled code, your test coverage report, your bundle size analysis — they have a correct state, and that state can be verified automatically.

A missing translation key is a build error. An untranslated string rendered to a French user is a broken feature. A locale file that hasn’t been synced to the TMS is stale code.

Once you treat it this way, the pipeline work becomes obvious. You already have automated checks for code correctness, test coverage, and bundle size. i18n coverage belongs in the same category, enforced the same way.

The teams that get this right are not the teams that care more about localization. They are the teams that stopped treating localization as someone else’s problem and put it in the pipeline where it belongs.

Before you go, a small meta-note. The i18n pipeline I described above is one I’m actively building with AI. I use Claude and a multi-agent setup to handle different stages of the workflow: scanning for hardcoded strings, extracting keys, flagging concatenation patterns. Then a semantic layer via Black Ice checks terminology consistency, style, and market availability — so a term that works in en-US gets validated before it assumes it works in de-DE or ja-JP. Writing about i18n infrastructure while building it with the same tools is, I’ll admit, a very specific kind of fun.

🫂 Thanks Julia!

Marcos back!

I want to send a deep Thank You to for sharing her experience on the Product Platform area and localization. To learn more from Julia, subscribe NOW to her newsletter 👇

The AI-Ready Localizer

The AI-Ready Localizer explores how multilingual ontologies, market intelligence, and data governance transform localization from translation into AI-powered, intent-driven global growth.

By Julia | Taking you global

🔖 Follow-up readings

The AI-Ready Localizer

Building Globally: A Practical i18n Guide

Internationalization (i18n) isn’t just a language feature. It’s a design constraint, a code architecture choice, and a product strategy…

Read more

a year ago · 22 likes · 1 comment · Julia | Taking you global

When you create the software, sometimes it’s difficult to find your blind spots. But time puts things in perspective, and so you can learn from your mistakes.

In today’s email, I want to share with you the 4 signals that your software is badly designed.

Rigidity

👉🏼 Rigidity is the tendency of software to be difficult to change, even in simple ways.

A system is rigid when a change in one module triggers a cascade of changes in other dependent modules.

The symptom: If you request a change estimated to take two days and it ends up taking two weeks because “one thing led to another,” you have a rigid system.

The cause: It’s usually excessive coupling. Everything is so tightly coupled that you can’t move one piece without it affecting the entire board.

🧐 Let’s see an example, and how you would solve it.

The Scenario: You have an OrderProcessor class with a massive switch statement for calculating shipping costs. If it’s “UPS,” it does one thing; if it’s “FedEx,” it does another. When you want to add “DHL,” you have to modify that class, forcing you to recompile and retest the entire order module.

The Solution: Strategy Pattern (or the Open/Closed Principle). Instead of an internal switch statement, you create a ShippingStrategy interface. Each carrier (UPS, FedEx, DHL) implements this interface. The OrderProcessor now only receives one strategy and calls calculate().

Result: To add a new carrier, you simply create a new class. You don’t touch the existing code.

Fragility

👉🏼 Fragility is the tendency of software to break in many places every time a change is made.

Unlike rigidity, the problem here isn’t the effort of the change itself, but the lack of control over the side effects.

The symptom: You fix a bug in the payments module, and mysteriously, the inventory report generator stops working.

The cause: This usually occurs when there are hidden dependencies or highly intertwined logic where modules know too much about each other’s inner workings.

🧐 Let’s see an example, and how you would solve it.

The Scenario: You have a global variable or a Singleton that stores the “System Configuration.” A developer changes the date format in that configuration for a specific report, and suddenly, the “Payroll” module stops processing payments because it expected the old format. The system broke in a place unrelated to the original change.

The Solution: Encapsulation and Interface Segregation.

Don’t allow everyone to access a global object. Divide the configuration into smaller interfaces (e.g., PayrollConfig, ReportConfig). Each module only sees what it needs.

Result: A change in the reports only affects the reporting interface, keeping payroll safe.

Immobility

👉🏼 Immobility is the inability to reuse software in other projects or even in other parts of the same project.

It occurs when the design is so entangled with its environment that extracting a feature is more costly than rewriting it.

The symptom: You need a validation function that you already implemented in another module, but when you try to copy it, you realize that it also includes the database, the user interface, and three external libraries.

The cause: A design that doesn’t separate business rules from implementation details (such as the database or the framework).

🧐 Yeah, let’s see an example, and how you would solve it.

The Scenario: You created a brilliant algorithm to validate ID numbers (national ID/tax ID). However, the algorithm is written within a UserRegistrationForm class that inherits from a UI library (like React or the Android SDK) and also directly calls the database to check for duplicates.

The Solution: Layered Architecture (Clean Architecture).

Extract the algorithm into a Pure Object Component (POJO) or Use Case. This code should not know anything about buttons or databases. The database is passed to it as an interface (Dependency Inversion).

Result: Now you can copy that validation file and paste it into any other project without carrying over the “garbage” from the interface or the database.

Viscosity

👉🏼 Viscosity refers to the resistance the system offers to doing things “right.”

It is divided into two types:

• Software viscosity: When it is much easier to add a “hack” or a dirty patch that follows the original design and keeps the architecture clean.

• Environment Viscosity: This occurs when the development environment is slow or inefficient (endless compilation times, tests that take hours). This tempts developers to resort to shortcuts to avoid the formal process.

🧐 Let’s see an example, and how you would solve it.

The Scenario: You need to add a field to a form. The “clean” design requires creating a database migration, updating the entity, updating the DTO, and updating the mapper. That takes 1 hour. But you can simply save that extra “hidden” data in a generic text field called “observations” in 5 minutes. If the system takes a long time to compile or testing is slow, you’ll choose the dirty way.

The Solution: Automation and Infrastructure Refactoring.

If the problem is with the environment (slow compilation), you need better machines or to modularize the project. If it’s with the software, you need tools like Lombok or automatic mappers (AutoMapper/MapStruct) that reduce repetitive code (boilerplate).

Result: Doing it right should be almost as fast as doing it wrong. If the right way is easy to follow, developers will follow it.

Alright! Let’s wrap up for today. These four signals (Rigidity, Fragility, Immobility, and Viscosity) are not just theoretical concepts; they are the “smells” that indicate your system is asking for help.

✨ Takeaways

Today’s email has been really software engineering-oriented. Long time since I dedicated one email to this, hope you like it from time to time.

• Design for change: A rigid system is a slow system. Use patterns like Strategy to decouple logic from execution.

• Protect your boundaries: Avoid global states and hidden dependencies to keep fragility under control.

• Decouple from the framework: Your business logic should be able to live anywhere. If it’s stuck in a UI component, it’s immobile.

• Make the “right way” the “easy way”: If doing it right takes too much effort, the system will eventually fill with hacks. Invest in your environment.

☝🏼 Remember: Bad design is not a life sentence. Identifying these signals is the first step toward refactoring and moving toward a more Incremental Architecture.

I’d love to hear from you. Have you identified any of these signals in your current project? Which one do you find the most difficult to fix?

Drop a message in the comments or reply to this email. I read and reply to all!

Best,
Marcos.

👉🏼 It is shipping it with confidence.

Because releasing software should not feel like a coin toss, especially not on a Friday at 6 p.m., when everybody is already mentally halfway into the weekend, and the margin for dealing with surprises is much smaller than we would like to admit.

If every release feels risky, the problem is usually not the release itself. The problem is the system behind it.

In today’s issue, I want to share a different way of looking at that feeling of uncertainty that appears right before going to production, and why, in most cases, it is not something you fix at release time, but something you design away much earlier in the process.

Let’s begin with the elephant in the room.

The invisible weight behind every release

👉🏼 Releases do not become stressful in isolation.

They accumulate friction over time, through a combination of small issues that individually seem manageable, but collectively create a system that is harder to reason about and, therefore, harder to trust.

Some of those signals usually look like this:

• Ownership is not completely clear, so when something goes wrong, there is a small but real hesitation about who should act first.

• Parts of the system are only fully understood by one or two people, which silently increases the perceived risk of touching them.

• Logs exist, but they do not really explain what is happening, forcing you to reconstruct the story under pressure.

• Alerts either come too late or too often, which makes them easy to ignore when they actually matter.

• Environments behave slightly differently, in ways that are not always obvious until something breaks.

None of these things breaks a release on their own.

But together, they create a system where every change feels heavier than it should, and that weight tends to show up exactly when you least want it to: right before going to production.

Confidence is not a feeling, it is a property

👉🏼 Many teams treat confidence as something emotional, something that needs to be discussed or agreed upon before releasing.

Do we feel safe releasing this?

But confidence is not something you convince yourself of in a meeting.

It is something your system gives you, almost by default, when the right properties are in place.

A system that behaves well tends to share a few characteristics:

• It is easy to understand, which means that most engineers can reason about what a change will do before it happens.

• Responsibilities are clear, so when something goes wrong, there is no ambiguity about who owns the next step.

• It explains itself through logs and signals that help you understand what is happening without guesswork.

• It behaves consistently across environments, reducing the number of surprises when moving to production.

When those pieces are in place, confidence stops being a discussion and becomes an outcome.

Where most teams get it wrong

👉🏼 The common mistake is trying to “fix the release” instead of fixing the system that produces that release.

That usually leads to adding more layers around the moment of deployment:

• More checks.

• More approvals.

• More manual verification.

• More last-minute coordination.

All of these can help in the short term, and sometimes they are necessary.

But they rarely address the root of the problem.

Because the release is just the moment where all the properties of your system are tested at once, under real conditions and real pressure.

• If the system is hard to understand, the release will feel risky.

• If the system is inconsistent, the release will feel unpredictable.

• If the system is fragile, the release will feel stressful.

Trying to fix the release without fixing the system is like trying to move faster on a road full of potholes; you might get away with it a few times, but the underlying problem is still there.

A simpler way to think about it

Instead of asking:

Is this release safe?

It is often more useful to ask:

Does our system make safe releases the default?

That shift may seem subtle, but it changes where you put your effort.

It moves your attention:

• From the moment of deployment 👉🏼 to the way the system is built.

• From last-minute checks 👉🏼 to everyday engineering practices.

• From reacting to problems 👉🏼 to designing systems that are easier to trust.

And that is where most of the leverage actually is.

Now, some homework for you.

A small exercise

Think about your last release, not just in terms of code, but in terms of experience.

Try to recall the moments where you slowed down, hesitated, or double-checked something “just in case”, even if everything looked correct on the surface.

Ask yourself:

• Where did I hesitate, even slightly?

• What did I feel the need to double-check before moving forward?

• Which part of the system made me feel uncertain or uncomfortable?

Those moments are not random but signals.

They are pointing to parts of your system that are asking for more clarity, more consistency, or better feedback.

👉🏼 If you start paying attention to those signals, release after release, you are not just making the next deployment safer. You are gradually building a system that is easier to understand, easier to operate, and ultimately easier to trust.

Shipping software will never be completely risk-free, but it should not feel like guesswork either.

And when it does, it is usually telling you exactly where to look.

Having this relationship forged through the years following you, if the price were acceptable, I would pay for it.

— Senior Software Engineer

I’m still open for feedback. Please, pass by 👇🏻

Now, let’s get back to today’s issue.

Everything started with a message from when we were finishing our Master's degree:

Marcos, what if we apply to this open possition at CERN together?

And I said

Yeah, don’t know… my english is really poor, you know?… don’t know if it’s worth it anyway… mmm… okeysh, let’s do it (what can I loose).

That was my Flashpoint, when everything started.

But let’s put a bit of context here.

“Stepping out of your comfort zone” is a phrase that has been worn out by overuse. It often sounds as if you aren’t constantly jumping into the void, you aren’t progressing.

But that’s not true in my experience, and I don’t believe in universal rules either.

Context matters, and a lot. What is a bold move for one person might be an irresponsible decision for another, depending on their current life stage.

However, there are moments when staying where you are is simply limiting your own growth. That’s where uncertainty comes in.

I know that could sound tough, but I always tell you I bring you real-life experiences, and real life is like that.

The context: From stability to chaos

About 13 years ago, my plan was linear: finish my degree in Oviedo, keep working there, and have a predictable life. It was a comfortable bubble.

But in 2013, the crisis hit hard in Spain. The company I was working with decided to let me go, and suddenly, that “stability” vanished. My first reaction was to look for the closest thing to what I already had: another job in Asturias, close to home, without overcomplicating my life.

That’s when Ángel, a good friend, sent me a link: a job opening at CERN.

“What am I even doing here?”

My tech stack at the time was PHP and MySQL. When I read “CERN,” my imposter syndrome kicked in immediately: “What am I going to do there? I build websites, not particle physics.”

Does it ring a bell to you?

But I asked myself a question that changed my perspective:

Why not?

Sometimes, that’s the only technical validation you need to apply for a role.

I passed the interviews and, three months later, I was landing in Geneva with two suitcases and a paper map in my hand. I was out of my comfort zone, and the feeling wasn’t one of “empowerment”; it was pure fear.

Reality at CERN: No instruction manual

I joined as a DevOps Software Engineer to work on the OpenStack infrastructure (the data center’s private cloud). But the real shock wasn’t technological; it was methodological.

In high-level environments, nobody sits next to you to tell you what to do step-by-step.

• The mission: “Improve the UI of this system.”

• The roadmap: It didn’t exist. You had to build it yourself.

That level of autonomy forces you to operate in a space where you can’t rely on routine. You either learn to navigate ambiguity, or you sink.

I’m not ashamed to admit that I didn’t know how to do that. Damn, I was thinking

Shit!, I want to come back home tomorrow!

But something changed inside of me. I managed to evolve. I managed to really understand why I was there, and the out-of-control situation helped my brain to figure it out.

What you gain when you let go of control

If you decide to take the leap (when your context allows it), two fundamental things happen for an engineer:

1. Your learning capacity multiplies out of necessity. You don’t learn because you want to add a checkmark to your CV; you learn because you have no other choice to get the job done and, of course, because that’s your goal!. You learn how to “learn fast,” which is the ultimate skill.

2. You ask for forgiveness instead of permission. When there’s no set path, waiting for 100% of the information is death by analysis paralysis. You start making decisions, failing fast, and correcting on the fly.

☝🏼 A necessary clarification

I don’t want to romanticize this. You don’t have to move abroad or work at CERN to “grow.”

These decisions only make sense if the timing is right. In my case, being laid off and having few strings attached created the perfect scenario. If I had different responsibilities or a different family situation, the risk might not have outweighed the benefit.

Stepping out of your comfort zone doesn’t have to be a radical change. It can be:

• Leading a technical initiative for the first time.

• Switching to a team where you don’t master the stack.

• Giving a talk in front of people who know more than you do.

✨ Final thought

Real growth happens when you operate slightly above your level of certainty. Not in absolute chaos (which is just noise), and not in total comfort (which is stagnation).

The useful space is right in the middle, where you can still think clearly, but you can no longer rely solely on what you already know.

The next time an opportunity comes your way that gives you a bit of vertigo, before dismissing it, ask yourself:

Why not?

I’m pretty sure you have a similar case. I would love to hear from you. Reply to this email or drop a comment in Substack, I read them all!

Thanks for your support and feedback, I really appreciate it!

You’re the best! 🖖🏼

𝘐𝘧 𝘺𝘰𝘶 𝘦𝘯𝘫𝘰𝘺𝘦𝘥 𝘵𝘩𝘪𝘴 𝘱𝘰𝘴𝘵, 𝘵𝘩𝘦𝘯 𝘤𝘭𝘪𝘤𝘬 𝘵𝘩𝘦 💜. 𝘐𝘵 𝘩𝘦𝘭𝘱𝘴!

𝘐𝘧 𝘺𝘰𝘶 𝘬𝘯𝘰𝘸 𝘴𝘰𝘮𝘦𝘰𝘯𝘦 𝘦𝘭𝘴𝘦 𝘸𝘪𝘭𝘭 𝘣𝘦𝘯𝘦𝘧𝘪𝘵 𝘧𝘳𝘰𝘮 𝘵𝘩𝘪𝘴, ♻️ 𝘴𝘩𝘢𝘳𝘦 𝘵𝘩𝘪𝘴

💚 On WhatsApp

💙 On LinkedIn

🩵 Bluesky

The Optimist Engineer has always been about helping engineers grow through better judgment, stronger technical thinking, and clearer decisions in real situations.

Over time, I realized that some topics deserve more depth than a weekly newsletter can give.

That is why I am preparing a paid version of The Optimist Engineer.

The free newsletter will continue as it is: useful ideas, lessons, and reflections on software engineering, technical leadership, and career growth.

The paid version will go further for readers who want to:

• go deeper into real engineering and career decisions,

• see more concrete examples and practical frameworks,

• understand not only what I think, but why I think it,

• and get a closer look at the lessons I learn while working.

This is not about publishing more for the sake of publishing more.

It is about creating a space for readers who want to move from reading ideas to applying them with more confidence.

There will be two main premium elements:

• First, a monthly deep-dive with a free section and a premium section. The public part will give you the core idea. The premium part will go deeper, with more detail, examples, visuals, and practical material. And note that I say “deep”, which does not necessarily mean “longer”.

• Second, a series of short audio notes called Thinking Out Loud. These will be small, frequent reflections from my day-to-day work: compact lessons, observations, and micro-learnings that are too immediate for a full article, but still worth sharing.

“Insightful, well-structured content that blends technical expertise with real-world experience.” — Angel Suarez, PhD, Product Development Manager

If you have found value in The Optimist Engineer so far, this new version is for readers who want to go deeper into the kind of thinking that can help them make better decisions in their own work.

So here is the simple question:

👉🏼 Would you be interested in paying for a premium version of The Optimist Engineer?

And if so, what kind of premium content would be most valuable to you?

Just hit reply, I read every response.

Thanks for being here and for reading The Optimist Engineer.

Marcos
The Optimist Engineer

I want to share something a bit different today.

Over the past months, I’ve been spending a lot of time thinking about The Optimist Engineer. What it is, what it’s becoming, and what I want it to be in the future.

When I started writing, the goal was simple:

👉🏼 Share useful ideas and real-world lessons that could help other engineers grow.

And honestly, I didn’t expect it to resonate the way it has.

Some of your replies, messages, and conversations have made me realize that this is not just a newsletter anymore. It’s something people actually find useful in their day-to-day work.

And that’s where this thought started.

Lately, I’ve been wondering what it would look like to take this one step further.

I’ve also shared these thoughts with , a friend of mine. Talking them through with someone I trust has helped me reflect more honestly on what this could become.

Not in terms of writing more.

But in terms of going deeper. Being more intentional. Sharing more of the thinking, the trade-offs, and the real decisions behind the work.

And with that idea, a question naturally appeared:

Would it make sense at some point to create a paid version of The Optimist Engineer?

To be honest, this is not an easy thought for me.

Part of it is practical.

I’ve never set up something like this before, and things like taxes, fiscal setup, and all the “non-writing” parts feel… unfamiliar and a bit intimidating.

And part of it is more personal.

There’s always that question in the back of my mind:

what if I build it… and no one is actually interested in paying for it?

I don’t have a clear answer to that yet.

What I do know is that I care a lot about keeping this space useful, honest, and worth your time.

So for now, I’m just exploring the idea. Thinking about what it could look like, and whether it would make sense at all.

I’ll share more thoughts on this soon.

Thanks for being here, and for reading The Optimist Engineer.

Marcos
The Optimist Engineer

What does a Tech Lead actually do during the week that a Senior Engineer doesn’t?

It’s easy to get lost in meetings, but true technical leadership is exercised through high-leverage technical tasks.

Today, I want to focus on the two “power moves” that will make you stand out: Architecture Reviews and Strategic Tech Debt Management.

1. Architecture Reviews: From Gatekeeper to Facilitator 🏛️

Many engineers think an Architecture Review is about being the “smartest person in the room” who says “yes” or “no” to a design. Wrong.

A Lead uses reviews to:

• Identify cross-team impacts: Does this change in the Monolith affect the new modular services we are building?

• Teach trade-off analysis: Don’t just point out a flaw; ask the team, “If we choose this database now, how hard will it be to migrate in 6 months?”

👉🏼 Leadership here is about Architecture Incrementalism.

You aren’t looking for the “Final Perfect Version”; you are ensuring the team takes a step forward without creating a legacy nightmare tomorrow.

2. Tech Debt: Stop Complaining, Start Managing ⚖️

We all have technical debt. Let’s not complain about it but manage it.

👉🏼 Growing into leadership means moving away from “we should rewrite this” toward “we will improve this incrementally.”

Here is how you lead through debt:

• The Debt Radar: Don’t just fix bugs. Identify which parts of the code are “high-interest debt”, the ones that slow down every single sprint.

• Negotiation: Your job is to translate “clean code” into “business value” for product managers. “If we spend two days refactoring this module, we will deliver the next three features 20% faster.”

Knowledge Pills 💊

If you want to start acting like a Tech Lead today, pick one of these tasks:

• Shadow a Review: Ask a Lead if you can join their next architecture sync. Don’t just watch the tech; watch how they ask questions to guide the team.

• The “Boy Scout” Rule at Scale: Don’t just leave the code cleaner; leave the architecture clearer. Document one undocumented decision this week.

• Categorize your Debt: Next time you see a mess, don’t just fix it. Tag it. Is it “Deliberate Debt” (we rushed for a deadline) or “Outdated Debt” (the system evolved)?

Wrap up ✨

👉🏼 Technical leadership is about reducing friction for your team.

When you master architecture reviews and debt management, you aren’t just “coding”; you are building an environment where everyone else can code better.

I’d love to hear your thoughts!

Which of these two tasks do you find more challenging: defending “Refactoring Time” to your manager, or giving feedback on a peer’s architecture without sounding like a “hater”?

Drop a comment below. Let’s build a better engineering culture together!

Stay optimistic and keep building.

Thanks for your support and feedback, I really appreciate it!

You’re the best! 🖖🏼

𝘐𝘧 𝘺𝘰𝘶 𝘦𝘯𝘫𝘰𝘺𝘦𝘥 𝘵𝘩𝘪𝘴 𝘱𝘰𝘴𝘵, 𝘵𝘩𝘦𝘯 𝘤𝘭𝘪𝘤𝘬 𝘵𝘩𝘦 💜. 𝘐𝘵 𝘩𝘦𝘭𝘱𝘴!

𝘐𝘧 𝘺𝘰𝘶 𝘬𝘯𝘰𝘸 𝘴𝘰𝘮𝘦𝘰𝘯𝘦 𝘦𝘭𝘴𝘦 𝘸𝘪𝘭𝘭 𝘣𝘦𝘯𝘦𝘧𝘪𝘵 𝘧𝘳𝘰𝘮 𝘵𝘩𝘪𝘴, ♻️ 𝘴𝘩𝘢𝘳𝘦 𝘵𝘩𝘪𝘴

💚 On WhatsApp

💙 On LinkedIn

🩵 Bluesky

One of the most common questions I get from Senior Engineers is:

How do I actually prove I’m ready for a Lead role?

Most people think it’s about writing more code or being the fastest at closing JIRA tickets. But here is the truth:

👉🏼 Leadership isn’t about the code you write; it’s about the decisions you enable.

The transition from Senior to Lead requires a fundamental mindset shift. You need to stop thinking in terms of “tasks” and start thinking in terms of “systems” and “impact.”

In today’s email, I share with you 3 pills of knowledge for you to thrive in this ride.

The Mindset Shift: From “How” to “Why” 🚀

When you are a Senior Dev, you focus on the how:

• How do I implement this function?

• How do I fix this bug?

When you step into Tech Leadership, you must pivot to the why and the what:

• The Individual Contributor (IC) builds the bridge.

• The Tech Lead decides where the bridge should go and ensures the whole team knows how to maintain it.

This shift is where most engineers struggle, but there’s a perfect “training ground” to practice this: System Design.

By the way, if you are looking for good System Design learnings, subscribe for free right now to the work done by 👇🏻

The System Design Newsletter

Download my system design playbook on newsletter signup for FREE

By Neo Kim

Leadership in Action: The ETL Example 🛠️

Let’s look at a practical example we’ve discussed in this other email: Designing an ETL (Extract, Transform, Load) architecture.

A Senior Developer might jump straight into the code, picking the trendiest library to move data from point A to point B. But a Tech Lead approaches it differently. They don’t just build an ETL; they make leadership decisions through design:

1. Contract over Code: They define the “Contract” between systems. They think about how this data pipeline affects the Data Science team or the Frontend.

2. Trade-offs as Strategy: They don’t look for the “perfect” tool. They weigh cost vs. scalability. “Do we need real-time streaming, or is a simple batch process enough for our current business stage?”

3. Mentorship through Architecture: They design the system so it’s easy for other developers to contribute without breaking things.

When you document these decisions, explaining the why behind your architecture, you are already performing the role of a Tech Lead. You are providing clarity, reducing risk, and empowering the team.

Knowledge Pills for Your Growth 💊

If you want to accelerate your path to leadership this month, try these three things:

• Own the “Non-Happy” Path: Don’t just design for when things work. Lead by defining how the system fails (observability, retries, alerts).

• Write for Others: Start writing RFCs (Request for Comments). If you can convince your peers that your architecture is the right one, you are leading.

• Stop Being the Hero: If you are the only one who can fix a specific system, you aren’t leading; you are a bottleneck. True leaders build systems that don’t need them to survive.

Wrap up! ✨

👉🏼 Technical leadership is a muscle.

You build it every time you take a step back from the IDE to look at the bigger picture. Whether you are refactoring a monolith or designing a new data pipeline, ask yourself: “How does this decision make my team better?”

Now, I want to hear from you!

What is the biggest challenge you’ve faced when trying to move from “doing” to “leading”? Is it the lack of time, or perhaps not knowing how to start the conversation with your manager?

Leave a comment below, I read and reply to every single one!

Stay optimistic and keep building.

Thanks for your support and feedback, I really appreciate it!

You’re the best! 🖖🏼

𝘐𝘧 𝘺𝘰𝘶 𝘦𝘯𝘫𝘰𝘺𝘦𝘥 𝘵𝘩𝘪𝘴 𝘱𝘰𝘴𝘵, 𝘵𝘩𝘦𝘯 𝘤𝘭𝘪𝘤𝘬 𝘵𝘩𝘦 💜. 𝘐𝘵 𝘩𝘦𝘭𝘱𝘴!

𝘐𝘧 𝘺𝘰𝘶 𝘬𝘯𝘰𝘸 𝘴𝘰𝘮𝘦𝘰𝘯𝘦 𝘦𝘭𝘴𝘦 𝘸𝘪𝘭𝘭 𝘣𝘦𝘯𝘦𝘧𝘪𝘵 𝘧𝘳𝘰𝘮 𝘵𝘩𝘪𝘴, ♻️ 𝘴𝘩𝘢𝘳𝘦 𝘵𝘩𝘪𝘴

💚 On WhatsApp

💙 On LinkedIn

🩵 Bluesky

Follow-up readings 🔖

☝🏼A Schema Registry acts as the central source of truth for data schemas, helping teams manage schema evolution, enforce compatibility rules, and facilitate seamless communication between distributed services.

In today’s issue, I will address:

• What a Schema Registry is.

• Benefits of Using a Schema Registry.

• Use Cases Where Schema Registries Are Essential.

• When Schema Registries Are Not Worth It

• Major Schema Registry Solutions Comparison.

Let’s start.

🧐 What a Schema Registry is

☝🏼A Schema Registry is a centralized repository for storing and retrieving data schemas.

👉🏼 It is designed to handle version control, ensuring that any evolution in the data structures is tracked and managed.

By maintaining a clear contract between producers and consumers, the registry enables reliable serialization and deserialization of data formats such as Avro, Protobuf, and JSON Schema, among others.

In a microservices architecture, during the sync and async communication, you have to ensure that the data you will write and read is compatible with your services.

👉🏼 Basically, the producer of the data could use a version of the data, version 1.2.0, and the consumers could use the same or an older version, like 1.1.0, without breaking either side. That’s the magic that a Schema Registry does for you.

☝🏼 Thinking about your code. The different Schema Registries offer SDKs for many languages, so you can serialize and deserialize data using the API offered by the SDK.

For example, when using an asynchronous API through Apache Kafka, you will have to configure your consumer with the deserializer class offered by the SDK from the Schema Registry you have chosen.

I already anticipated one of the major benefits of using a Schema Registry, but let’s explore more.

💡 Benefits of Using a Schema Registry

I could enumerate some, like:

• Centralized Management: It provides a single source of truth for all data contracts, simplifying maintenance across microservices. And having a single source of truth in a distributed system means a lot!

• Schema Evolution: The registry supports versioning and controlled evolution, which allows for backward, forward, or full compatibility as business requirements change.

• Data Quality and Consistency: Enforcing compatibility rules helps prevent errors that might occur due to mismatches in data structure between services.

• Reduced risk of breaking change: With clear contracts defined, teams can build services independently while ensuring they communicate correctly using standardized data formats.

• Enhanced Monitoring and Governance: It provides audit trails and version histories, enabling teams to track changes and troubleshoot issues more efficiently.

How does it sound to you?

But still, is a Schema Registry something you really need? Let’s explore the use cases.

🎯 Use Cases Where Schema Registries Are Essential

1. Schema evolution without breaking producers or consumers

In event-driven systems, data models evolve over time. Fields are added, renamed, deprecated, or reorganized. In a distributed architecture where producers and consumers evolve independently, these changes can introduce incompatibilities if they are not managed properly.

👉🏼 A schema registry allows schemas to be versioned and compatibility rules to be enforced so that changes can be introduced without breaking existing services.

Without a registry:

• Each team manages its own data model in code.

• Schema changes can break existing consumers, and problems are often discovered only at runtime.

• Teams need to coordinate deployments to avoid incompatibilities.

With Schema Registry:

• Schemas are stored in a centralized and versioned location.

• Compatibility rules, such as backward or forward compatibility, can be enforced.

• Incompatible changes are detected before the producer can publish messages.

2. Explicit contracts between teams

In microservices architectures or streaming systems, events act as interfaces between different services or teams. For these interactions to be reliable, the structure of the messages must be clearly defined and accessible to all participants.

👉🏼 A schema registry allows the data model to become a formal, versioned contract that producers and consumers can rely on.

Without a registry:

• The schema usually lives in code or informal documentation.

• Consumers need to infer the message structure themselves.

• It is common to see mismatches between documentation and the actual messages being produced.

With Schema Registry:

• The schema becomes a central source of truth.

• Producers and consumers rely on the same contract definition.

• Versioning allows the contract to evolve in a controlled way.

3. Automatic validation of messages

A common issue in data platforms or event-driven systems is the presence of messages with incorrect structures or missing fields. These problems can cause failures in consumers or even break entire data pipelines.

👉🏼 A schema registry enables automatic validation to ensure that messages comply with the registered schema before they are published or processed.

Without a registry:

• Producers can send messages with inconsistent structures.

• Consumers must implement manual validation logic.

• Errors are often detected late, after the message has already entered the system.

With Schema Registry:

• Messages are validated against the registered schema.

• Producers cannot publish invalid data.

• Data quality and consistency across the system are improved.

At this point, you may think:

Damn! I need to put a Schema Registry right now!

Wait, and let’s see when it does not make sense.

❌ When Schema Registries Are Not Worth It

1. Only one producer and one consumer that are tightly coupled

When the producer and the consumer belong to the same system, the same repository, or the same team, schema evolution can be managed directly in the code and through coordinated deployments.

👉🏼 In this situation, introducing a registry adds an additional operational dependency without solving any real decoupling problem.

Without a registry:

• The schema lives in the same repository as the producer and the consumer.

• Changes to the data model are deployed in a coordinated way.

• Integration tests validate that both sides remain compatible.

With Schema Registry:

• An additional service must be operated and maintained.

• Serialization configuration and schema management introduce extra complexity.

• There is little practical benefit because the system is already coordinated.

2. The system is still in a prototype or exploration phase

During the early stages of a project, data models tend to change quickly while ideas and architectural decisions are being validated. At that stage, the priority is iteration speed rather than strict governance of data contracts.

👉🏼 Introducing a registry too early adds friction to development and slows down the evolution of the system.

Without a registry:

• Schemas can evolve rapidly together with the code.

• Changes can be made without formal compatibility processes.

• The team can iterate and refactor freely.

With Schema Registry:

• Schema changes require version registration and compatibility validation.

• Additional steps are added to the development workflow.

• Development speed decreases in a phase where experimentation is important.

3. Messages do not represent structured data

A Schema Registry is designed to manage and validate structured data with clearly defined fields. If messages contain opaque payloads such as binary blobs, compressed files, or encrypted content, there is no meaningful structure to register or validate.

👉🏼 In this situation, introducing a registry does not provide any technical benefit.

Without a registry:

• Messages are treated as opaque payloads.

• Consumers handle the interpretation logic.

• Only basic metadata may be validated if needed.

With Schema Registry:

• There is no real structure to register or validate.

• Compatibility rules cannot provide meaningful guarantees.

• Infrastructure is added without delivering functional value.

Before finishing for today, let me give you a comparison table for the Schema Registries I’ve analyzed recently.

📊 Major Schema Registry Solutions Comparison

This table provides an overview of key features and capabilities of each Schema Registry solution, making it easier to compare and select the best fit for specific needs.

✨ Takeaways

Let’s wrap up for today!

A Schema Registry acts as a central source of truth for data contracts in distributed systems. In microservices or event-driven architectures, where multiple producers and consumers evolve independently, maintaining a centralized repository of schemas allows all services to share a clear and versioned definition of the message structure.

One of its most important benefits is enabling schema evolution without breaking producers or consumers. Through versioning and compatibility rules such as backward or forward compatibility, teams can introduce changes to data models while ensuring that existing services continue to function correctly.

In addition, a Schema Registry significantly improves data quality and consistency. By automatically validating messages against the registered schema before they are published or consumed, it prevents malformed or incomplete data from entering the system and causing failures that are often difficult to detect at runtime.

However, it does not always provide value. When there is only one tightly coupled producer and consumer, or when a system is still in a prototype phase where data models change frequently, introducing a Schema Registry can add operational complexity without solving a real problem.

That’s it for today!

If you are building event-driven systems or microservices, sooner or later you will face the challenge of keeping data contracts consistent across services.

A Schema Registry can solve that problem, but as we saw, it only makes sense in the right context.

Have you used a Schema Registry in your architecture? What worked well, and what challenges did you face?

Leave a comment below, I read and reply to every single one!

Stay optimistic and keep building,

Thanks for your support and feedback, I really appreciate it!

You’re the best! 🖖🏼

𝘐𝘧 𝘺𝘰𝘶 𝘦𝘯𝘫𝘰𝘺𝘦𝘥 𝘵𝘩𝘪𝘴 𝘱𝘰𝘴𝘵, 𝘵𝘩𝘦𝘯 𝘤𝘭𝘪𝘤𝘬 𝘵𝘩𝘦 💜. 𝘐𝘵 𝘩𝘦𝘭𝘱𝘴!

𝘐𝘧 𝘺𝘰𝘶 𝘬𝘯𝘰𝘸 𝘴𝘰𝘮𝘦𝘰𝘯𝘦 𝘦𝘭𝘴𝘦 𝘸𝘪𝘭𝘭 𝘣𝘦𝘯𝘦𝘧𝘪𝘵 𝘧𝘳𝘰𝘮 𝘵𝘩𝘪𝘴, ♻️ 𝘴𝘩𝘢𝘳𝘦 𝘵𝘩𝘪𝘴 𝘱𝘰𝘴𝘵.

Share

🔖 Related readings

System Design Classroom

Event-Driven Architecture (EDA) is exciting until you deal with event versioning.

Or you can use an Adapter but with a twist. Yes, like in 90% of the problems in Software Development, there is a Pattern that will help you find a smart solution…

Read more

2 years ago · 62 likes · 9 comments · Raul Junco

Javarevisited Newsletter

24 Microservices Patterns for Experienced Developers

Hello guys, if you are working in Microservice projects then it make sense to learn different Microservices design pattern and principles, not just to make your architecture more robust but also to understand existing projects…

Read more

2 years ago · 36 likes · javinpaul and Soma

The Software Frontier

System Design Simplified: A Beginner's Guide to Everything You Need to Know (Part 9.1)

Hello everyone, Lorenzo here! (As always, running a bit behind schedule—but I promise, this one will be worth the wait…

Read more

a year ago · 4 likes · Lorenzo Bradanini

Today’s issue features a special guest . Here is Jorge’s introduction.

Hi! I’m Jorge Castaño, a Tech Lead helping software engineers grow technically and step into leadership with confidence. I share lessons from leading engineering teams to help you avoid the common mistakes of your first leadership roles.

I want to recommend Jorge’s newsletter for all those Spanish-speaking Software Engineers seeking growth and Engineering Leaders looking for learning resources.

Vivir del Software

Manual de Supervivencia Developer | Consejos de carrera para destacar en el mundo del Software | ¿PEC? Te suscribes | Gratis incluso si eres DevOps

Por Jorge Castaño

Without taking any more time, I'll hand the word 🎤 over to Jorge.

Congratulations, you made it. You finally have your senior developer position. It’s been a tough road.

But if you thought this was the end, I have bad news: you can’t retire yet. With any luck, you still have 30 years of daily meetings ahead.

Reaching the senior floor is not the last stage of your career, which is why today I want to talk to you about the 3 possible paths that open up in front of you.

The mindset shift

Sorry to keep bringing bad news, but the first thing you need to take the next step is to change the way you think. To reach senior, you learned in depth how programming works, which algorithms are most efficient, and which designs best fit each situation. You focused on the technical side.

Many of us have tried to progress using the same tools: more technology, more specialization, more technical depth. But now that’s no longer enough. #sad

The next level is not about knowing more. It’s about learning that your impact no longer depends solely on what you produce with your own fingers. The next step means making decisions, guiding your team, and multiplying the work of others.

It’s an uncomfortable change that requires letting go of everything that defines us: being good programmers. The challenge is no longer measured by the tickets you close; it’s more diffuse. But it’s also bigger, since every decision you make has a greater impact.

The three paths

Ok, my next role involves a greater impact on my team, but how?

Well, there are 3 possible directions. None is better than the others; you’ll have to figure out which one you want to walk.

The technical track (Individual contributor)

You’re still an engineer, but your influence is no longer limited to your own code. At the early levels — Tech Lead — you still have a concrete team, clear deliverables, and you keep writing code. Enjoy it.

As you move toward Staff / Principal Engineer, the game changes: you define technical direction, reduce uncertainty in problems others don’t even know how to start, and influence without hierarchical authority.

Climbing the technical track may mean you code less and less, but you’ll be very close to the solutions being implemented. And that feels almost the same as building them yourself. Almost.

Engineering Management

This is the path that scares and attracts people the most at the same time. You leave code as your main tool — not necessarily forever, but as a priority — and people become your job. Your success is no longer measured by what you produce, but by what your team produces.

This role requires completely different skills: listening, communication, and difficult conversations. It can be daunting because we go from being programmers to being managers. But watching your team grow and being able to help them directly is also a rewarding job.

This track change requires training — don’t think you’ll suddenly be able to handle such a different role without help. The problem is when your company doesn’t support you through it, which is most of the time. #sadder

Product Manager

Possibly the least obvious path for a developer, but an increasingly common leap in the AI era. If you find yourself asking why things get built, this is your move.

Moving into product means starting to operate in the space of what and why before how. The intersection of what the user needs, what the business wants, and what the team can build. You’ll need to prioritize, say no, and explain why.

Developers who move into product have an advantage that no non-technical PMs can replicate: they understand the real cost of decisions. But be careful: it’s dangerous to be stuck on the how when your job now is to define the what.

How to choose your path?

There’s no right answer, but there are right questions. Take some time with this, because thinking is hard work.

The most common trap is choosing by elimination or by inertia: “I don’t see myself managing people, so technical track” or “I was offered a manager role and took it.” That’s not choosing, that’s going with the flow. #saddest

Three questions to help clarify:

What gives you the most energy today?

Not what you’re good at, but what’s your fuel? Solving a complex technical problem, unblocking someone on your team, or understanding why a product isn’t working.

What are you willing to leave behind?

Every path involves a real trade-off. The technical track means letting go of direct control. Management means letting go of the code. Product means letting go of technical certainty. What loss can you live with?

Where do you want to be in three years?

Picture your day-to-day. What your meetings look like, what problems you’re solving, who you’re talking to. Choose carefully, but don’t delay the decision. Worst case, you can always go back to the technical track.

That’s it! Think about those three questions calmly before you decide your next step.

Here’s a prompt to talk it through with your favorite AI:

I’m a Senior developer thinking about my next career step. I want to explore three possible paths: the technical track (Tech Lead, Staff or Principal Engineer), Engineering Management or Product Manager.

Ask me questions one at a time to help me figure out which path fits me best. Don’t give me the answer upfront. First I want to explore what gives me energy, what I’m willing to leave behind, and where I see myself in three years.

At the end, give me your honest take on which path seems most aligned with what I’ve shared, and why.

Thanks, Marcos, for allowing me to speak to your community.

If you want to talk more about this or anything else, feel free to reach out on Linkedin.

🫂 Thanks Jorge!

Marcos back!

I want to send a deep Thank You to Jorge Castaño for sharing his experience with all of us. To learn more from Gábor, take a look at his newsletter 👇🏻

Vivir del Software

Manual de Supervivencia Developer | Consejos de carrera para destacar en el mundo del Software | ¿PEC? Te suscribes | Gratis incluso si eres DevOps

Por Jorge Castaño

Thanks for your support of my work here, really appreciate it!

If you enjoyed this article, then click the 💜. It helps!
If you know someone else will benefit from this, ♻️ share this post.

How much easier would things be if those decisions were written down, clear, and useful for whoever joins later?

In today’s email, you will learn how to stop your technical decisions from disappearing into Slack threads and endless PRs.

The real problem: technical decisions that disappear

Most problems in software systems don’t come from syntax errors.

They come from forgotten reasoning:

• A decision is made on a call.

• Someone summarizes it in Slack.

• Three months later, nobody remembers why that path was chosen.

Then someone proposes a “better” solution.

And the debate starts again.

Rework. Friction. Endless PR comments.

👉🏼 RFCs are the antidote to collective technical amnesia.

They create memory.

What an RFC actually is in your day-to-day work

Forget Internet standards.

In your team, an RFC is simply a short, structured document that explains:

• Why this change is needed

• What is being proposed

• What trade-offs exist

• What could go wrong

That’s it.

👉🏼 It’s about raising the quality of technical thinking before code is written.

And that alone changes the level of conversation.

Why writing RFCs builds authority and helps you persuade

☝🏼 Let’s be honest: Authority in engineering does not come from seniority alone. It comes from clarity and transparency.

Writing RFCs builds both in public.

👉🏼 You demonstrate structured thinking and invite participation.

Anyone can have an opinion in a meeting.

Very few people can:

• Clearly define the real problem.

• Separate assumptions from facts.

• Lay out alternatives.

• Explain trade-offs.

• Anticipate risks before someone else mentions them.

An RFC forces you to do exactly that.

And there’s something even more important: Many technically sound proposals fail because they arrive fully baked. When developers are not involved early, they don’t feel ownership. And when people don’t feel ownership, they resist.

👉🏼 Sharing an RFC as a draft changes the dynamic. It becomes a conversation instead of a decision announcement.

When you should write an RFC

☝🏼 Not every change needs one.

But write an RFC when the decision:

• Changes the architecture.

• Introduces a new or expensive dependency.

• Modifies a public API.

• Affects multiple teams.

• Has long-term impact beyond a single ticket.

👉🏼 Just to give you a real example: The last time I wrote an RFC was to propose how to implement the AGENTS.md framework in the repos of the Engineering Organization.

AI Native Compass

From AGENTS.md to sub-agents: structure and best practices

If you work in Platform Engineering or on a development team, you need to understand one thing: subagents ≠ MCPs…

Read more

4 months ago · 4 likes · Marcos F. Lobo 🗻🧭

Now, an important part.

How to handle feedback without turning it into an opinion war

☝🏼 RFCs don’t eliminate disagreement but they structure it.

To deal with this situation, a few simple rules help:

• Separate facts from preferences.

• Set a time window for feedback.

• Escalate only when needed.

• Document the final decision clearly.

And one important principle: No silent vetoes.

👉🏼 If someone blocks the proposal, ask them to write a counter-proposal using the same structure.

Where to write RFCs

I like to use Git to publish my RFCs because I find it a good tool for:

1. Reach my audience, a.k.a. developers.

2. A Pull Request permits comments and contributions.

So, if you want to start writing RFCs, my suggestion for you is:

• Create a new repository.

• Where the README.md file explains what the repo is and how to create RFCs.

• Also, you will have an RFC template that the people can (must) use to contribute their RFCs.

That’s it!

So far, you have some clarity about the RFCs. Now, let me give you the template I’m using nowadays. Click the button below to receive it for free 👇🏻

🎁 Get RFC template for free

✨ Summary

RFCs are not ceremonies. They are not corporate theater. And they are definitely not paperwork for the sake of process.

They are thinking tools.

They force you to slow down just enough to clarify the problem before jumping to the solution. They turn opinions into arguments. They transform isolated ideas into shared decisions. And over time, they build something most engineering teams lack: technical memory.

Writing RFCs will not make your code compile faster. But they will make your decisions stronger. They reduce friction. They create alignment. They make discussions sharper and shorter. And they make your reasoning visible.

And, look:

• If you want to grow as an engineer, keep writing code.

• If you want to grow in influence and authority, start writing decisions down.

Hope you enjoy today’s email. I know I made some bold arguments, and I hope you consider them when you plan your next proposal.

Thanks for your support and feedback, I really appreciate it!

You’re the best! 🖖🏼

𝘐𝘧 𝘺𝘰𝘶 𝘦𝘯𝘫𝘰𝘺𝘦𝘥 𝘵𝘩𝘪𝘴 𝘱𝘰𝘴𝘵, 𝘵𝘩𝘦𝘯 𝘤𝘭𝘪𝘤𝘬 𝘵𝘩𝘦 💜. 𝘐𝘵 𝘩𝘦𝘭𝘱𝘴!

𝘐𝘧 𝘺𝘰𝘶 𝘬𝘯𝘰𝘸 𝘴𝘰𝘮𝘦𝘰𝘯𝘦 𝘦𝘭𝘴𝘦 𝘸𝘪𝘭𝘭 𝘣𝘦𝘯𝘦𝘧𝘪𝘵 𝘧𝘳𝘰𝘮 𝘵𝘩𝘪𝘴, ♻️ 𝘴𝘩𝘢𝘳𝘦 𝘵𝘩𝘪𝘴

💚 On WhatsApp

💙 On LinkedIn

🩵 Bluesky

In detail, today you will learn:

• The goal of an MCP.

• Components and responsibilities.

• Delivery options.

Before jumping into it, I just wanted to let you know that I am writing another newsletter on how to move from Cloud Native foundations to AI‑powered platforms. There, you will find more details about how to work with AI in the enterprise world. You can subscribe here 👇🏻

AI Native Compass

From Cloud Native to AI Native

By Marcos F. Lobo 🗻🧭

Let’s continue now.

🎯 Goal of an MCP

The MCP defines a standardized way for environments and tools (IDEs, CLIs, agents) to request context, such as files, metadata, secrets, telemetry points, policies, etc., from a Context Provider (an agent or service).

This context is used to feed LLMs/Models that perform assistance tasks (autocompletion, test generation, security analysis, etc.) without exposing the entire repository or unnecessary secrets.

🧱 Components and Responsibilities

• IDE Plugin / MCP Client

  • User interface, event hooks (cursor, selection), UI for context approval.

  • Communicates with the Agent via local socket (Unix socket/named pipe) or localhost HTTP/gRPC.

• MCP Agent

  • Orchestrates context gathering (files, git, build graph, dep).

  • Applies policies, redaction, and minification.

  • Caches results and maintains provenance history.

  • Interacts with secret/telemetry providers.

  • Calls models (local or remote) or forwards the response.

• Model Provider / LLM

  • Can be a cloud endpoint (OpenAI, Anthropic, Azure) or a local model (Llama, Mistral).

  • The Agent must be able to redirect prompts and enforce size limits.

🚀 Delivery options for MCP servers

At the time of delivering an MCP server, the deployment decision is not just technical. The aspects you have to consider are:

• Latency.

• Security.

• Developer experience.

• Operating costs.

• Governance.

The main options are discussed in more detail below.

Native Binary

An executable that the developer installs locally and that runs as a system process.

Advantages:

• Maximum performance and low resource consumption.

• Direct access to the filesystem, Unix sockets, and OS resources.

• Immediate startup (no cold start).

• Better integration with IDEs and local tools.

Disadvantages:

• Need for cross-platform builds (Mac, Windows, Linux).

• More complex version and upgrade management.

• Distribution and binary signing require a robust pipeline.

When to choose it:

• Teams with a strong focus on Developer Experience.

• Need for minimal latency.

• Environments where local access to the repository is critical.

Docker Container

The Agent runs as a Docker container locally.

Advantages:

• Full consistency across operating systems.

• Simplifies Agent dependencies and libraries.

• Easy versioning (image tags).

• Compatible with enterprise environments where Docker is already standard.

Disadvantages:

• Additional containerization overhead.

• Volume permission management (can be tricky).

• Slightly more complex UX (requires an active Docker container).

I personally don’t find these advantages really critical, but I wanted to add them from an objective point of view.

When to choose it:

• If all developers already use Docker.

• If you want to minimize “works on my machine” issues.

Cloud Service

The Agent runs as a shared service (internal or external SaaS). Clients connect remotely.

Advantages:

• Centralized policies and drafting.

• Unified observability.

• Easy to implement RBAC and auditing.

• No complex local installation required.

Disadvantages:

• Higher latency (network round-trip times).

• Privacy risks if the context contains sensitive code.

• Greater security complexity (TLS, IAM, isolation).

When to choose it:

• Large organizations with compliance needs.

• Globally distributed teams.

• When strict traceability is required.

✨ Summary

In today’s email, you get an overview of the MCP server, its architecture, and the best approaches to deliver it to your customers.

Architecturally, a typical MCP-based application has three clear building blocks:

• The IDE plugin/client (UI hooks and event triggers).

• The MCP Agent (context gathering, policy enforcement, redaction, caching, and orchestration).

• The Model Provider (local or cloud-based models).

Each component has distinct but complementary responsibilities.

Choose wisely the way to deliver your MCP. Nowadays, delivering MCP servers via Docker is my preferred choice because it offers a good balance between performance and version management.

I would love to hear about your experiences implementing MCP servers. Reply to this email or put a comment in Substack.

Thanks for your support and feedback, I really appreciate it!

You’re the best! 🖖🏼

𝘐𝘧 𝘺𝘰𝘶 𝘦𝘯𝘫𝘰𝘺𝘦𝘥 𝘵𝘩𝘪𝘴 𝘱𝘰𝘴𝘵, 𝘵𝘩𝘦𝘯 𝘤𝘭𝘪𝘤𝘬 𝘵𝘩𝘦 💜. 𝘐𝘵 𝘩𝘦𝘭𝘱𝘴!

𝘐𝘧 𝘺𝘰𝘶 𝘬𝘯𝘰𝘸 𝘴𝘰𝘮𝘦𝘰𝘯𝘦 𝘦𝘭𝘴𝘦 𝘸𝘪𝘭𝘭 𝘣𝘦𝘯𝘦𝘧𝘪𝘵 𝘧𝘳𝘰𝘮 𝘵𝘩𝘪𝘴, ♻️ 𝘴𝘩𝘢𝘳𝘦 𝘵𝘩𝘪𝘴

💚 On WhatsApp

💙 On LinkedIn

🩵 Bluesky

Your CEO, CTO, and even your CPO are telling you:

Use the AI as much as possible!

Or this other (my favourite)

So will be able to deliver faster than before!

I will not jump into this debate (today), but into another: the development of the in-house services that implement the Model Context Protocol, to be used by AI Agents in the IDE of the developers.

I’ve seen many folks in Platform Engineering teams start writing MCP-based services meant to be used by the dev teams, and I wondered:

Hey, does this actually solve a problem for the dev teams?

In today’s issue, I want to share with you my vision about when an in-house MCP-based service makes sense.

Before jumping into it, I just wanted to let you know that I am writing another newsletter on how to move from Cloud Native foundations to AI‑powered platforms. You can subscribe here 👇🏻

AI Native Compass

From Cloud Native to AI Native

By Marcos F. Lobo 🗻🧭

Now, let’s get back to our business.

First of all, is this an automation?

Platform Engineering teams are meant to provide frameworks, CI/CD workflows, libraries, processes, and best practices to the Software Engineering teams so they can ship value to customers fast.

Platform Engineering teams have a great responsibility: choose the right solution so that Software Engineering teams will embrace and onboard the solution smoothly.

Since Software Engineering teams work with IDEs, and thanks to the existing integration between IDEs (VS Code, IntelliJ) and AI Agents, or existing IDEs like Cursor or Windsurf, one of the steps that could make sense is:

Let’s create an MCP-based service so developers can use it from their IDEs.

This is a great approach.

However, I’ve seen many Platform Engineering teams failing on this. Why?

👉🏼 They implemented an MCP-based solution when the feature teams needed just an automation.

Do not mix AI with automation; they are different things.

So, next time you think the solution is an MCP-based service, ask yourself the following:

Can the work be done by an automation?

Is an in-house MCP-based service needed?

Look at this huuuge list of MCP servers available, many of them are official from their providers.

So, another question to ask yourself?

Will my MCP-based service solve a problem that isn’t already solved by existing MCPs?

I’ve intentionally made that question plural.

Connecting multiple MCP-based services to tools like Cursor or Windsurf already allows an AI Agent to solve problems that span multiple sources.

In fact, AI Agents can already orchestrate across the configured MCPs to resolve those problems.

So the real question is:

Why add another MCP that acts as a wrapper?

Maybe yes!, maybe no!

I’ve raised a couple of reflections that now your brain is trying to plug and play with the rest of your ideas. In order to help you, I will now list when it makes sense to create an MCP and when it does not.

When does an in-house MCP-based service not make sense?

• Small organizations (1–2 teams) where the operational overhead of the MCP outweighs the benefits.

• Top priority: developer speed and minimal friction (you prefer direct adapters in the IDE).

• High team autonomy: with very different rules and an aversion to centralization, the MCP will become a source of political friction.

• When the cost of maintaining adapters/compatibility outweighs the benefits, e.g., too many vendors with unstable APIs.

When does an in-house MCP-based service make sense?

• You have >=10–20 teams with different policies and want global consistency (rulesets, RBAC, auditing).

• You need correlation/dedupe between findings from multiple scanners (SAST, SCA, linters, Sonar, etc.) to prevent one bug from appearing as three.

• Compliance/audit requirements: logging who automated what, blocking pull requests based on corporate policy, and evidence retention.

• You’ll want to enforce cross-functional policies, like legal or privacy rules affecting all repositories, and enforce controlled downgrades when providers fail.

Let’s wrap up for today.

✨ Summary

Keep this in mind:

👉🏼 Just because you can implement an MCP-based service to solve a problem doesn’t mean you should.

From there:

• Make an assessment of the problem you need to solve.

• Is it something you can solve with automation?

• Be sure you have the right expertise in the team to implement these kinds of tools.

Thanks for your support and feedback, I really appreciate it!

You’re the best! 🖖🏼

𝘐𝘧 𝘺𝘰𝘶 𝘦𝘯𝘫𝘰𝘺𝘦𝘥 𝘵𝘩𝘪𝘴 𝘱𝘰𝘴𝘵, 𝘵𝘩𝘦𝘯 𝘤𝘭𝘪𝘤𝘬 𝘵𝘩𝘦 💜. 𝘐𝘵 𝘩𝘦𝘭𝘱𝘴!

𝘐𝘧 𝘺𝘰𝘶 𝘬𝘯𝘰𝘸 𝘴𝘰𝘮𝘦𝘰𝘯𝘦 𝘦𝘭𝘴𝘦 𝘸𝘪𝘭𝘭 𝘣𝘦𝘯𝘦𝘧𝘪𝘵 𝘧𝘳𝘰𝘮 𝘵𝘩𝘪𝘴, ♻️ 𝘴𝘩𝘢𝘳𝘦 𝘵𝘩𝘪𝘴

💚 On WhatsApp

💙 On LinkedIn

🩵 Bluesky

Money is important, more and more every day, and when you are in the cloud, holding the money is a real challenge 💸.

That’s why, in today’s issue, I will give you an overview of OpenCost, a CNCF project.

But first things first, what OpenCost is?

It’s an open-source, vendor-neutral project that brings real-time cost visibility and allocation to Kubernetes and cloud infrastructure so engineering teams and platform teams can make data-driven decisions about efficiency and showback/chargeback.

Nice definition, right? For me, that kind of definition are okeysh, but I really need to understand what it does.

🤔 What OpenCost actually does

• Measures & allocates cloud and Kubernetes costs in near real-time (CPU, memory, storage, network, GPU, etc.).

• Maps cloud billing to Kubernetes concepts, so you can answer “how much did team X spend last week?” or “which deployment is causing the spike?”

• Supports multi-cloud and on-prem via integrations with AWS/Azure/GCP billing APIs and customizable pricing models.

Another thing I see super useful for real life is that OpenCost can give you the money you burn by namespace. Why is it important for me? Because, usually, the resources from the different dev teams are deployed in separate namespaces, hence, each dev team can see how much their stuff costs.

From there, the next step is obvious. Having namespace costs allows you to:

• Allocate expenses directly to teams or products (if each team uses its own namespace).

• Quickly identify which namespace is consuming the most resources or money.

• Integrate with showback/chargeback processes within your platform.

Last but not least, I think it’s important to mention that OpenCost is Kubernetes-native: you typically deploy it into your cluster(s) (Helm charts available), and it relies on existing metrics sources (Prometheus) and cloud billing data for price lookups.

🎯 Problems it solves

When you start deploying your SaaS product into a Kubernetes clusters you face many challenges. Some of the ones related to costs are:

• Opaque Kubernetes spend. Kubernetes abstracts resources, but that abstraction hides who/what is actually driving costs. OpenCost restores accountability.

• Ownership breaks down in shared Kubernetes platforms. Kubernetes clusters are shared by design. Cloud providers bill at the account or subscription level, but teams think in terms of services and products. Without a clear ownership model, questions like “which team is driving this cost?” are hard to answer. Manual mappings and spreadsheets 😱 appear as workarounds.

• Kubernetes hides the true cost of “idle”. Over-provisioning, shared nodes, and autoscaling make it hard to understand idle capacity and inefficiencies. OpenCost surfaces these hidden costs, allowing platform teams to reason about efficiency in concrete, measurable terms.

🧐 State of the project

OpenCost is a CNCF project that progressed from Sandbox into Incubating. It was accepted into CNCF in mid-2022 and promoted to Incubating in October 2024, reflecting growing community adoption and governance maturity.

The project is actively maintained (GitHub repo, releases, and community contributors) and has continued to publish roadmaps and year-in-review notes describing frequent releases and expanding integrations.

Recent public updates indicate priorities around refining cost models, improving supply-chain security for cost data, and adding features to better track emerging workloads (for example: AI/ML usage costs).

✨ Summary

Many companies include the cost assessment before implementing the solution. Others (lucky you) just jump into implementation, and then the problem of understanding the cost comes.

In any case, whether you made an estimation, or you just don’t know, nowadays (always?), you must have visibility on the costs of the applications and resources deployed in your Kubernetes, and OpenCost is one of the options available.

That’s all for today!

I would love to hear about your experiences using OpenCost or any other tool for measuring the costs of cloud applications. Drop me a comment or reply to this email; I will read it and come back to you!

Thanks for your support and feedback, I really appreciate it!

You’re the best! 🖖🏼

𝘐𝘧 𝘺𝘰𝘶 𝘦𝘯𝘫𝘰𝘺𝘦𝘥 𝘵𝘩𝘪𝘴 𝘱𝘰𝘴𝘵, 𝘵𝘩𝘦𝘯 𝘤𝘭𝘪𝘤𝘬 𝘵𝘩𝘦 💜. 𝘐𝘵 𝘩𝘦𝘭𝘱𝘴!

𝘐𝘧 𝘺𝘰𝘶 𝘬𝘯𝘰𝘸 𝘴𝘰𝘮𝘦𝘰𝘯𝘦 𝘦𝘭𝘴𝘦 𝘸𝘪𝘭𝘭 𝘣𝘦𝘯𝘦𝘧𝘪𝘵 𝘧𝘳𝘰𝘮 𝘵𝘩𝘪𝘴, ♻️ 𝘴𝘩𝘢𝘳𝘦 𝘵𝘩𝘪𝘴

💚 On WhatsApp

💙 On LinkedIn

🩵 Bluesky