Forem: Raffael Eloi

Stop Using Switch Statements: Keyed Services in .NET - A Practical Approach

Raffael Eloi — Fri, 06 Mar 2026 00:09:04 +0000

Have you heard of Keyed Services? Do you know when to use them? Have you ever needed multiple implementations of the same interface and ended up writing a big switch or if-else block to decide which one to use?

Today, I'll show you a new tool for your software engineering toolbox and a hands-on approach using a POC project on my GitHub, where you can see the full implementation.

In this article, I'll show you how Keyed Services work and how they can simplify event-driven designs using a practical example.

What are Keyed Services?

Before .NET 8, registering multiple implementations of the same interface was possible, but resolving a specific implementation was not straightforward.

Typically, you would inject IEnumerable and manually choose the correct implementation using conditions or metadata.

But with Keyed Services, a built-in dependency injection feature introduced in .NET 8, you can register multiple classes for the same interface using a key.

Why is that important?

There are scenarios where we can reduce the number of if-else statements and achieve a cleaner solution using these keys.

Especially when handling events, we can build a solid implementation that is easy to extend using Keyed Services.

When should you use Keyed Services?

Keyed Services are useful when:

You have multiple implementations of the same interface
The correct implementation depends on runtime data
You want to avoid switch / if-else logic
You want a solution that is easy to extend

Common scenarios include:

Event handlers
Notification channels (Email, SMS)

How does it work?

Bear with me for this example:

I have an EventHandlerFactory that receives an event and then redirects it to the responsible handler.

Incoming Event
      │
      ▼
EventHandlerFactory
      │
      ▼
Keyed DI Resolution
      │
      ▼
Specific EventHandler

Here's an interface that represents that:

internal interface IEventHandlerFactory
{
    Task HandleEvent(string eventName, object eventData);
}

Each event handler should implement this interface

internal interface IEventHandler
{
    Task HandleAsync(object eventData, CancellationToken cancellationToken);
}

Now let's create three event handlers for our mock scenario: PurchaseOrderEventHandler, InvoiceEventHandler, and PaymentEventHandler.

Each handler will look like this:

internal class PaymentEventHandler : IEventHandler
{
    public Task HandleAsync(object eventData, CancellationToken cancellationToken)
    {
        // Implement the logic to handle payment events here
        return Task.CompletedTask;
    }
}

Now, here's the first implemenation of the EventHandlerFactory :

internal class EventHandlerFactory(IServiceProvider serviceProvider) : IEventHandlerFactory
{
    public const string PurchaseOrder = "PurchaseOrder";

    public const string PaymentProcessed = "PaymentProcessed";

    public const string InvoiceProcessed = "InvoiceProcessed";

    private readonly IServiceProvider _serviceProvider = serviceProvider;

    public async Task HandleEvent(string eventName, object eventData)
    {
        var cancellationToken = new CancellationToken();

        if (eventName == PurchaseOrder)
        {
            IEventHandler handler = _serviceProvider.GetRequiredKeyedService<IEventHandler>(PurchaseOrder);
            await handler.HandleAsync(eventData, cancellationToken);
            return;
        }

        else if (eventName == PaymentProcessed) 
        {
            IEventHandler handler = _serviceProvider.GetRequiredKeyedService<IEventHandler>(PaymentProcessed);
            await handler.HandleAsync(eventData, cancellationToken);
            return;
        }

        else if (eventName == InvoiceProcessed) 
        {
            IEventHandler handler = _serviceProvider.GetRequiredKeyedService<IEventHandler>(InvoiceProcessed);
            await handler.HandleAsync(eventData, cancellationToken);
            return;
        }


        throw new InvalidOperationException($"No handler found for event: {eventName}");
    }
}

For dependency injection, the only thing we need to do is pass the key when registering the dependency:

serviceCollection.AddKeyedScoped<IEventHandler, PurchaseOrderEventHandler>(EventHandlerFactory.PurchaseOrder);
serviceCollection.AddKeyedScoped<IEventHandler, PaymentEventHandler>(EventHandlerFactory.PaymentProcessed);
serviceCollection.AddKeyedScoped<IEventHandler, InvoiceEventHandler>(EventHandlerFactory.InvoiceProcessed);

This is a good implementation. We can clearly see which event handler is responsible for each eventName. However, we can make it even better:

internal class EventHandlerFactory(IKeyedServiceProvider serviceProvider) : IEventHandlerFactory
{
    public async Task HandleEvent(string eventName, object eventData)
    {
        var cancellationToken = new CancellationToken();
        IEventHandler handler = serviceProvider.GetRequiredKeyedService<IEventHandler>(eventName);
        await handler.HandleAsync(eventData, cancellationToken);
    }
}

Final thoughts

I hope you learned something new today. This concept was pretty new to me until a couple of weeks ago.

Here's the repository with the full implementation of the POC scenario:

https://github.com/Raffael-Eloi/keyed-services-poc

Also, feel free to follow me on GitHub and LinkedIn:

Github: https://github.com/Raffael-Eloi
Linkedin: https://linkedin.com/in/raffael-eloi
My site: https://raffaeleloi.dev

If you enjoy topics like this, follow me here or connect with me on LinkedIn. I regularly share content about .NET, software architecture, and engineering practices.

The cost of AI in your career

Raffael Eloi — Thu, 22 Jan 2026 09:41:52 +0000

For the past three years, we have been in the AI era. In the beginning, it was hard to adopt AI, and only a small portion of people were using it, but now it is the biggest trend, and is present in almost all areas.

I remember when I was in college and we started using AI in our subjects. At the time, the answers were not very good and were followed by a lot of mistakes. However, my teachers were already predicting that this would be the "future of search".

I believe AI is really powerful, and also can improve your productivity, but, it can also be your downfall. Using AI in the way that I see many people using it can cause long-term damage that, unfortunately, they are not even aware of.

The cliché, but still relevant quote: "With great power comes great responsibility".

Learn by doing

How many times in your life you truly learned something just by listening to it? or even by reading it? or only by passively watching things get done?

My first question right here is: How much can we learn by passively watching AI do everything?

I think this question can be broken down into different levels.

If you have never done something and you ask AI to do everything for you, I really believe you cannot extract much from that experience. I'm going to use programming as an example: if you want to create something from scratch and you do not fully know how to do it, using AI to build everything for you is a very bad long-term choice.

All the learning that comes from making mistakes is gone, and you may start thinking that everything works like magic all the time, which is definitely not true.

When we delegate the possibility to learn something new to AI, we are also delegating mistakes, risks, fun, knowledge, confidence, mindset and growth.

You make your choices, and then your choices make you.

Curiosity and Critical thinking

Are you only interested in getting things done, or do you also care about how things get done? How do you know the way you did something was the best choice? How can you know different approaches?

Unfortunately, this topic is not discussed as much anymore. I think the fast-delivery industry is trying to shut this topic down, this is no longer how the world wants to work. I can see a tendency to get things done as quickly as possible, and this approach bypasses critical thinking. The end result? A long-term damage, as we discussed.

In the new AI world, we do have more power in our hands, but what the industry seems to care about most is velocity, and the number of things we can get done. At this pace, using AI, we are producing bad outputs, and the reason is easy to find: We don't want to think anymore.

But why would we think? We have a tool that builds everything we want, why would we care about that?

If you want to overcome this new tendency, here are a few things you can do:

Learn how the sausage is made

Do not take every answer or output for granted. Learn the pros and cons of the choice and understand why that choice was made.

Do not take the easy road

It is very easy to see things working without thinking about how they work, but don't do that, swim against the tide, learn the basics behind what you are building, try to go deeper, read books, take notes yourself.

Sometimes, it is better to do something manually that you have never done than to use AI and extract nothing from the experience you had.

When was the last time you did something by yourself? How long has it been since you wrote something yourself, really paying attention to every detail, instead of writing the minimum possible version and asking AI to improve it?

Developer vs User

This section is more related to the software engineering area.

As developers, we build software and solve things that do not necessarily involve code. At the same time, writing code, in most cases, is the biggest part of our job.

The question, "How do you spend most of your time, as a developer or as a user?", which I heard during a college seminar presentation, has stuck with me since then. I remember taking some actions in my career after hearing it, it made me realize that I wanted to invest more time thinking and building things as a producer, and not as a consumer of the technology.

When we delegate everything to AI, we put ourselves back into the consumer/user perspective again. Sometimes, we give up our greatest power.

I was making some commits using the github interface, and when I was creating a pull request, Copilot suggested a commit message. At first glance, I thought, "that's cool", but then I noticed that I hadn't really thought about what I had built. I was just clicking buttons automatically, without reflecting on my work.

The next time you are building something, ask yourself: "Am I being a developer in control and aware of what I'm building? or am I just a user consuming every output AI gives me?"

The cost of the HYPE

Every time I open my browser or linkedin, I see a lot of articles, courses, videos, and content about prompt engineering and how to get better at using AI.

I know it is good to learn the basics and understand how to get more assertive answers and outputs from AI. However, in my experience, the fundamentals and the basics related to your field are the most valuable.

In the software engineer context, there are topics that never get old, and this knowledge makes the biggest difference in your career. Learning about DNS, memory management, software architecture, code design, CI/CD, cloud computing, and so on will sharpen you more than any prompt you learn.

You don't need to ignore the hype, I would only suggest learning the basics before jumping into the hype.

The cost of AI in your company

Have you thought about the impact of AI in your company? What is the cost of coding faster using AI? Is there any impact on the teams using AI? What about the domain knowledge, is it still relevant? How do you measure code quality when using AI?

Measuring code quality using AI

Well, that's a tricky one. AI has been trained on a large amount of code from many sources, and it is hard to define what good code and bad code really are.

Would you trust AI to decide whether code is good or not? and based on which concepts? I think most of the discussions in the software engineering area are about principles and concepts we have, and whether or not we should follow them.

AI can read entire codebases easily... Humans cannot.

The impact on teams using AI

First, I would like to start talking about the domain knowledge. Companies used to care more about the domain knowledge, and from my experience, it plays a huge role in day-to-day operations, bug fixing, and generating value through new features.

If we start using AI to solve problems in day-to-day operations instead of training people to build strong domain knowledge, the long-term outcome can be harmful. What if you need to fix something urgent in production? Would you trust AI entirely to do it? How likely is it that AI will fully understand the context and provide the best solution for the scenario?

The combination of AI and someone with strong domain knowledge is powerful, but choosing only AI is not a wise decision.

Second, if we start isolating people to work only with AI, how will knowledge sharing happen? There are things that only day-to-day conversations or a pair programming session can provide. Also, if we isolate people to work only on AI, we lose interactions and, consequently, teamwork.

The cost of replacing a good employee is far higher than the cost of an AI tool.

Final thoughts

I am not advocating against AI. I really believe AI is a great tool that can help us and speed things up for us a lot. I use AI daily, and I feel productive when using it.

My main point here is that we should always be in control of it, not the other way around. We should criticize its outputs, learn the basics and foundations, and sometimes do things by ourselves, embracing the learn by doing process.

Do not delegate your entire career to AI, take ownership of your decisions. This path will require one of the hardest things in life: discipline. But don't give up on it, the more you exercise discipline, the easier it becomes.

Let's create more original content, thoughts, and ideas in an AI world where so much feels generic.

SwimAgainstTheTide

Creating my portfolio with Antigravity AI

Raffael Eloi — Thu, 15 Jan 2026 21:25:25 +0000

I decided to write a detailed article describing my entire journey creating my portfolio with Antigravity.

The sequence:

Idea
Approach / Strategy
AI Choice
Key concepts and choices for the frontend app
Experience / Journey
AI workflow
Result
Final thoughts

1. Idea

While I was searching for opinions about the WeAreDevelopers event, which I would like to participate in one day, I found an interesting opinion on the dev.to website. After reading it, I came across a pop-up from the dev.to promoting a Frontend challenge using AI.
I already wanted to create my portfolio and understand AI better, so it was a perfect opportunity to kill two birds with one stone.

2. Approach

My idea was to use the learn by doing method. I didn't want to spend many hours learning about the AI, instead, I wanted to see how intuitive my chosen AI is and how far I could go without having to provide very technical prompts.

3. AI Choice

In the challenge, we had three AI options (from Google), and I chose Antigravity. I'm going to be honest here: I chose it because I liked the name (you've probably done something similar at some point in your life, so don't judge me).

I watched the introduction video on the Antigravity website, and they presented the following method:

Implementation plan
Pre-requisites
Proposed Architecture
Implementation steps
Verification plan

4. Key concepts and choices for the frontend app

Frontend:

Next.js (I don't have much familiarity with it, so that's why I chose it)
TypeScript

Key concepts:

Easy to change
Separation of concerns
MVC Architecture
Pretty UI
Feature-based layout (~~atomic design~~)

5. Experience / Journey

I will highlight some moments in the process of creating the portfolio that made me reflect on certain AI approaches.

Downgrading Node version

In order to use the latest version of Next.js, the node version installed on my machine was not compatible. Instead of suggesting an upgrade, the AI decided to downgrade Next.js (I stopped it before that).
This caught my attention: why didn’t the AI suggest upgrading Node.js instead?

Accessing web pages

During the process of creating my portfolio, I gave the AI some public links to my GitHub and LinkedIn profiles. The AI opened up a browser and fetched the information.
That was pretty impressive, and it was interesting to watch the steps it took.

All the entities in a single file

The AI's first choice was to create all the entities inside a single file. Although this is a very basic issue, I often notice the AI choosing the most "cheap" and "compact" solutions. We need to pay attention to that. AI can read an entire codebase easily, we cannot.

Atomic design... literally

This one is kind of funny. In the prerequisites I provided to the AI, I defined the Atomic Design, but it turns out the AI built the following structure:

Well, that was not my intention. I wanted to use Atomic Design, but not the literal folder names. I preferred a more organic separation instead of using concept names for each folder.

Component delegation

I don't know Next.js very well, so it was not clear to me how things were working. After some back and forth with the AI, we came up with the idea of component delegation, which I really enjoyed.

6. AI workflow

I really liked Antigravity's approach. It consists of two or three steps, depending on the prompts you provide. These steps are represented as markdown files and require your approval.

Proposal

The AI provides a markdown file containing some ideas and options you can choose from, followed by the pros and cons of each choice.

Implementation plan

Before getting your hands dirty, the AI shows you the plan, the steps, and the goal for the action it is trying to implement.
Having this step gave me a really good feeling about what the AI is thinking and how it plans to achieve the result. It is much better than letting the AI do everything and reviewing the output only at the end.

Walk Through

After you approve the implementation plan proposed by AI, you can see what has been implemented and the final result.
Overall, this is a pretty good idea.

7. Result

This is my application, and I'm going to break down the architecture and explain my choices.

app: It contains the pages
components: related to the UI and the feature-based approach
models: entities representing the domain
services and data: I decided to mock a JSON file with the resume structure as follows:

Resume

Basic info
Experiences
Education
Extras

For this section, I mocked the file with my data, but I kept it this way because, in the future, it can retrieve data from an API and generate the profile automatically.

8. Final thoughts

In the end, it was a really fun experience. I was able to learn more about Antigravity AI, Next.js, and Google Cloud Run. I believe that the more we expose ourselves to challenges, the more we sharpen our minds and skills.

Antigravity surprised me. It was a good experience using it, especially with the implementation plan, which was a really cool idea.

I bought a domain, and it was pretty easy to link it to my portfolio using Google Cloud. Check it out: (https://raffaeleloi.dev)

Also, I was able to learn more about the turbo pack (a really fast compiler written in Rust).

I didn't spend a lot of time on this challenge, but even so, I had fun and managed to build my portfolio, which has been on my to-do list for a long time.

Before I forget, I have been searching for a text editor that would help me avoid distractions, and I found this one zenpen.io. I used to write down my ideas, and I really recommend it.

My repo: https://github.com/Raffael-Eloi/portifolio-updated

Any comments or suggestions are welcome.

Building better softwares: The power of building effective abstraction

Raffael Eloi — Sat, 18 May 2024 23:35:42 +0000

The first time I heard about abstraction was in my programming classes during my degree. We were studying the four pillars of object-oriented programming: Abstraction, Encapsulation, Polymorphism, and Inheritance.

I was fascinated by the idea of modeling the real world in the software we were building. It was a new concept for me, and it took a lot of practice to get used to thinking this way.

However, my understanding of abstraction has grown. It's more than just replicating the real world in software, as we learned in our object-oriented programming classes. Abstraction can be applied at different levels, and while it might seem complex at first, it doesn't have to be.

In this article, I'll explain how abstraction applies to code design and how it can help you gain a better understanding of the technology world. By using effective abstractions, you can build better software that is easier to maintain and understand.

The levels of abstraction

As software engineers, it's crucial to handle abstraction appropriately for different scenarios. We need to adjust our communication and focus based on the context we are in.

When meeting with stakeholders, we can't use the same technical language that we use within our engineering team. In these situations, the main goal is to understand the business, domain, and strategy as thoroughly as possible.

On the other hand, when discussing solutions, infrastructure, and architecture with the team, we should avoid focusing on specific code or programming languages. These are high-level conversations aimed at determining the best ways to manage our microservices and applications.

Therefore, there are various levels of abstraction to consider, and we must tailor our questions and thinking to the right level at the right time with the right people. Recognizing these levels of abstraction has helped me understand the power of context.

But what about low-level solutions? How can we identify abstraction in the software we are building, and how does it work?

Abstraction is life

When designing software, we deal with use cases that represent user actions within our system. Abstraction is essential. By defining the responsibility of an abstraction, we shape it based on the context and purpose we've established.

Creating a new abstraction is like bringing something to life. We need to clearly define its responsibility and purpose. This is why I particularly enjoy working with interfaces. They allow us to define clear contracts for our abstractions, ensuring that each part of the system has a specific role and interacts with others.

Working with interfaces

A well-defined interface acts as a contract for our abstraction. It's like bringing something to life and saying, "Your purpose is to only do this, and do it well." We don't need to worry about the details of how it will be done; the interface provides a stable contract that defines what the abstraction is and what it offers.

This approach aligns with the "D" in the SOLID principles: the Dependency Inversion Principle (DIP). DIP states that we should depend on abstractions rather than concretions. By following this principle, we create flexible and maintainable systems that can adapt to change more easily.

The combination of pieces

In software design, I think of interfaces like puzzle pieces. Each piece has a well-defined contract and purpose, allowing us to use them precisely where needed.

Working with interfaces provides stability when making changes to the code. No matter how much a concrete class changes, as long as it adheres to the contract, the consumers of that interface remain unaffected.

Using interfaces to define abstractions also supports TDD. With the mockist approach, I can mock the behavior of external abstractions and focus on the expected behavior of the current abstraction I am building. This ensures that each piece of the puzzle fits perfectly and functions as intended.

Whose responsibility is this ?

When designing use cases, we often tend to centralize all behaviors and business rules in a single service or use case. However, a well-designed use case is actually a combination of multiple abstractions working together.

Example:
In a finance software, consider a use case that generates an invoice. The flow might look like this:

Verify if the requested user has permission
Get the invoice
Calculate the tax
Generates the invoice

It's not ideal for this use case to handle all business rules. Instead, it should delegate specific responsibilities to abstractions designed for those tasks.
Building a high quality software requires high quality questions.
To create cohesive use cases, we need to ask the right questions:

Whose responsibility is this ?
How many reasons does this use case have to change ?
Should we create an abstraction to handle this specific business rule?
Is this business rule within the scope of the abstraction I am building?
Is this cohesive?
Can someone without much context understand this use case?

A possible solution:

Have a dependency on an abstraction that handles permission verification
Get the invoice value
Have a dependency on an abstraction that handles tax calculation
Have a dependency on an abstraction that generates the invoice in the required format

Conclusion

The beauty of this approach is that it allows you to see things from different perspectives and at various levels of abstraction. Understanding which level to focus on helps in establishing better communication and a clearer understanding of both problems and opportunities within the business.
Good design begins with asking the right questions, and the ultimate goal is simplicity. Designing software is an ongoing process; there is always room for improvement. We can continuously refine our designs by learning from our mistakes and through regular practice.

References

How the ego hinders growth in your software engineering career

Raffael Eloi — Sun, 28 Apr 2024 13:50:56 +0000

In the fast-paced world of software engineering there is always a great amount of work to do, backlogs to implement, new products to be developed, bugs to fix and refactors to be made. And when we sum this up with the velocity that the technologies grow and evolve today, we can see that this area is not only about skill but mindset.

To deal with this amount of responsibilities, it’s crucial that we continue to learn and be open to new ways to do things, read and observe how the others are doing and always try to search ways to optimize our work and reduce our cognitive load.

I think that is in this point that the most people fail, I’m not saying that if you do not do that you will not be successful or something like that, but what I’ll try to show you is that while we have a strict and not flexible mindset it can be really probably that you’re not using all the potential and capacity that your mind can have.

“I only use this technology because it is the best”

Usually in this area we have a lot of discussion and repercussion about what is the best technology and tool to use, and we be only strict to a single tool or language we lose some opportunities to learn something new and have a better and experienced opinion for when and which scenario is the best for each tool or technology.

All the time when I worked with someone that is really specialist in some tool, language or area I can see a lot of things from a different perspective, and I came to the conclusion to myself that we tend to not like the things that we don’t know.
Despite my preferences in terms of language and tools, it would be really prepotent to affirm that these are the best options available in the market if I haven’t tried a lot of options that exist today.

Give yourself a chance to learn something that you don’t like or think you don’t like and take your own conclusion. It will be a win-win situation because if you try and really do not like it you now have a real experience with that and can really argue with a better pov the reasons you don’t like it, but otherwise if you like it, that’s the magic, you won against your pride and can be humble enough to admit that in this area exist great tools to be used.

“I will not accept the opinion/suggestion of someone with a lower position”

Sometimes we are really attached to the title of our position in our jobs and we tend to think that we are our position instead of we are occupying the position that we have and it can change overnight.

The first question that I observe people do when they get together with a group of people from the same area is “what is your position in the company?”. I don’t particularly like this question, because it tends to imply that the level of credibility of your opinions will be characterized by the answer of this question.

Once I saw a video of Celest Headlee in a TED presentation in youtube (10 ways to have a better conversation | TED) which tells that everyone knows something we don’t.
In this video in the same way that we can learn a lot talking to the people and knowing their histories we can learn from everyone from whatever level of seniority.
Every senior started as an intern or junior.

“My way of doing things is the only right way”

Today we have many videos, books and courses talking about different ways of doing things, which methodology to use and why we should use it. But the truth is that none of this is a universal truth and each company carries out the process according to its own scenario.

The problem in my opinion is when we have the opportunity to try something different that can generate more value and we don’t do it because of the status quo “we always did like that” or because of our ego “I cannot go back in my opinion because I already said that the other way of doing is better”. In either case the result is a lose-lose or a stagnant performance.

One presentation that really opened my mind about it was the Simon Brown The lost art of software design that talked about Up Front Design and how we can create models and diagrams that facilitate the way we see our product and abstraction we’re building. In this video it is good to know that in addition to having a broad opinion about certain terms, you can still be flexible and have an open mind to the possibility of creating a middle ground.

“If I ask for help I will be seen as a bad professional”

If you are truly immersed in the world of ego, simple things that boost us and our careers can be seen as a threat and prevent you from achieving better prospects.

The phrase “If all you have is a hammer, everything looks like a nail” fits very well here, if your ego is not regulated everything can seem like a threat, and for me the best thing we can do for ourselves is to be in the position of an apprentice.

Don't be afraid to ask for help and accept your own ignorance, we can only improve the things we are not good at, so if you have nothing to improve, perhaps your view of yourself is a little distorted.

“I will not listen to this opinion because I do not agree with it”

This one is really interesting, because I struggle with this regularly, sometimes i think about it “why should I see this video if I do not agree with this topic” and when I accept that the video can teach me something I don’t know and I watch the video I always gain something, I either reinforce what I really don’t agree with or I learn something new.

One of the great personal examples I can give is the practice of TDD. I never thought about using this methodology because it didn't make sense to me, but today I can't see myself without it and it's perhaps the best thing I've learned.

Conclusion

In this post I tried to talk about my experience and my feelings regarding my career. All opinions have a very partial and personal point of view, but also contain references to videos, presentations and also books I have read.

Despite being labeled as a software engineering topic, this topic can be applied to any area of your life and career (if you agree, of course).

By transcending ego and embracing a growth mindset, we unlock our full potential in all aspects of life and career.

References

Recommendations

The benefits of TDD that go beyond the code

Raffael Eloi — Sun, 18 Jun 2023 12:21:24 +0000

As software developers, we are constantly faced with the task of solving problems and constructing new solutions through code. So all the time there’s something to do and in general even the small things are a sequence of a lot of steps to get the things done.
This raises important questions: Where do we begin? Which task should we prioritize for development? How can we effectively organize our thoughts to maximize productivity and maintain control over the development flow?

One of the best options to solve this issue is to use the TDD process. The TDD practice is not about tests or coverage, it can be one of the things that you win when you use that, but that’s not the main point, if you think that TDD is just about testing you misunderstood the real meaning.

The TDD can be a guide to develop the business rules needed. When we use TDD thinking about scenarios and abstractions instead of tests and coverage we can have a lot of benefits that are not only code related but also benefits even to our mental health.
Here’s some benefits that you can get using the TDD practise:

Scenarios serve as valuable guides

We always have some behaviors and scenarios to implement and the best way to start implementing is to set up an expected scenario that will force you to think in a different perspective because you need to imagine what is the best input and output for the abstraction that you are building. That’s really powerful because you start to think about business rules and abstraction instead of implementation’s details and by distancing ourselves from the small details of code we can get the big picture. When we start to develop something we should not be driven by “How” we can do it, but “What” we need because thinking in a high level of abstraction can put you in a software engineer position with an abroad vision instead of a software developer just focused on code and syntax.

You get constant feedback

Sometimes it is hard to know if the features that we are building are working correctly and we don’t get the feedback of the status until we finish. When we use TDD it can be a relief because we can divide the feature in small parts and use the scenarios as a guide. For each step of the process we get the feedback (RED, GREEN, REFACTOR) what is good for our brain mechanism of reward.

It helps you with anxiety

Almost all of the software developers have anxieties when they have to build something. It’s pretty common, we want to get things done to get another task and so on, but that’s not healthy and the TDD can help you with that. When we define that we’ll start with a scenario and we have constant feedback is a nice way to work. It gives you the feeling that you are in control and you also know that what you’re building is working.

You are able to improve your software whenever you want

As we evolve over time, our past versions become stepping stones towards better expertise and experience. It's natural to reflect on our software design and envision superior solutions compared to our previous work. However, without the practice of TDD, making changes becomes arduous and prone to disastrous outcomes.

TDD empowers developers to embrace constant change and enhance their code design at any given moment. By adhering to the "boy scout rule" of leaving the code cleaner than we found it, TDD enables a mindset of continuous improvement. This freedom to make changes instills a gratifying sense of control, especially when it allows us to challenge the status quo and strive for better solutions.

In Venkat Subramaniam's conference video, "Refactor your language knowledge portfolio - we are what we can code," he offers profound insights into how the programming language we use shapes our thoughts, and how our environment influences our growth as software developers. This prompts contemplation on how software practices, principles, and processes can impact our lives as a whole. If we fail to adopt good practices that ensure the expected behavior of our systems and neglect to make necessary changes, we are forced to accept the status quo. This acceptance can permeate into our personal lives, limiting our potential for growth and improvement.

You can divide the problem in small steps

Instead of trying to tackle all the tasks simultaneously, TDD encourages a more systematic and efficient workflow. By following TDD principles, you can enhance your development process and create small, simple components. This aligns with the famous quote by Julius Caesar, "Divide and conquer," which emphasizes the power of breaking down larger problems into smaller, more manageable ones. Adopting TDD not only helps you prioritize and focus on crucial features but also promotes an essentialist mindset, allowing you to build robust solutions step by step.

Illustration by Liz Fosslien

This publication about the benefits and perception of TDD is not a scientific study. All the information, perception and opinion is based on my experience using this practice every day.

I would like to thank Marcelo Torres and Kassio Santana who are amazing people for all their help and support during the writing process. I'm very happy to have you in my life.

In the references, I will let everyone know that it was important to consolidate the concept and value of the practice of TDD in my life.

References:

Illustration by Liz Fosslien - https://www.fosslien.com/
Dave Farley - https://www.youtube.com/@ContinuousDelivery
Otavio Lemos - https://www.youtube.com/@otaviolemos
Dev Eficiente - https://www.youtube.com/@DevEficiente
Venkat Subramaniam’s video - https://youtu.be/zajUPJI19ZQ