DEV Community: Renan Martins

Resilience Through Adaptability: Solving the Problem, Not the Process

Renan Martins — Tue, 06 Jan 2026 15:00:00 +0000

Plans change, APIs break, and priorities shift. It is simply part of the job.

What separates great teams from average ones isn’t their ability to avoid change, but their ability to adapt to it without losing focus. In a world of rigid roadmaps, the most successful teams are those that view a plan as a starting point rather than a final destination.

Flexibility Is Strength, Not Chaos

Being flexible does not mean working without a plan. On the contrary, it means understanding that plans are tools designed to help us navigate, not rules that must be followed at the expense of reality. When requirements shift, flexible teams do not waste time mourning the old plan. They immediately ask, “How can we adjust?” instead of “Why did this happen?”.

This mindset shift is the foundation of team resilience. It turns a potential source of frustration into a moment of collective problem-solving.

The Pragmatic Engineer’s Dilemma: Speed vs. Perfection

One of the ultimate tests of professional flexibility happens during a production crisis. As engineers, we are trained to value "best practices" and clean architecture. However, flexibility requires the wisdom to know when the context demands speed over elegance.

If you discover a critical production error and realize a simple fix (even if it doesn’t follow every best practice) can restore service in five minutes, while the "perfect" solution would take five days, you must be flexible enough to choose the fast path.

Fix the fire first: Apply the best solution you can within the time you actually have to stop the bleeding.
Acknowledge the debt: Choosing a quick fix isn't about being a bad engineer, it's a strategic trade-off to protect the user experience.
Plan the future: Flexibility requires a follow-up. You must plan the "right" fix as a future improvement to clear the technical debt you just created.

A team that refuses to be flexible during an outage because they "only write perfect code" is failing the business. True professionalism is knowing when to use a bandage and when to perform surgery. You fix the fast way in the time that you have, then you plan the future improvement.

What Flexibility Looks Like in Practice

Flexibility is a daily habit, not just a crisis response. It shows up in small but significant ways:

Adjusting sprint goals when priorities evolve or a new blocker is discovered.
Welcoming new ideas mid-development, even if it means changing a minor implementation detail.
Helping teammates outside your usual scope when needed, such as a developer helping with documentation or manual testing.
Being open to feedback even when it challenges your view or requires you to redo work you were proud of.

The Cost of Rigidity

When teams are too rigid, they become fragile. They stick to the original plan even when it no longer makes sense, leading to "feature building" for the sake of checking a box rather than delivering value. Rigid teams often focus more on following the rules than solving the problem, which eventually leads to friction and missed opportunities.

A flexible team isn’t unpredictable, it’s resilient. By being willing to change, you ensure that the team's energy is always focused on the most impactful work available.

Balance Between Stability and Adaptability

A flexible team isn't one without structure. You still keep processes, but you don’t let them become cages. It’s like writing code: clean architecture gives you the confidence to refactor safely.

If your team has mastered communication, stays organized, and shares knowledge, you have the foundation needed to change without breaking the system or the team's spirit. Stability provides the safety net that makes adaptability possible.

Final Thought

Flexibility is professionalism under uncertainty.

The best teams don’t fight change, they grow through it. In the world of software, the only constant is change. The faster you learn to embrace it, the better your team and your product will be.

✅ That's all, folks!

💬 Let's Connect

Have any questions, suggestions for improvement, or just want to share your thoughts?

Feel free to leave a comment here, or get in touch with me directly on LinkedIn — I’d love to connect!

Knowledge Sharing: Strong Teams Share What They Know

Renan Martins — Tue, 16 Dec 2025 21:04:37 +0000

If only one person knows how something works, your team doesn't really know it yet.
After years of working in different teams, I've learned that long-term success doesn't come from individual brilliance. It comes from shared understanding.
Teams that rely on a few key people may move fast at first, but they become fragile.
One vacation, one sick day, or one resignation is enough to slow everything down.
Knowledge sharing isn't just a nice-to-have.
It's what turns individual expertise into team strength, and effort into sustainable progress.

Why Knowledge Sharing Really Matters

Code changes, tools evolve, and people move on.
But when knowledge is shared, the team stays strong and independent.
When it isn't, a single absence, vacation, or resignation can slow down or even freeze an entire project.
When information isn't shared, progress becomes dependent on individuals. Shared knowledge turns a group of individuals into a resilient team.

Daily Sharing Builds Alignment

Some of the most valuable knowledge sharing happens in small moments.

Daily meetings are not just for status updates, they are opportunities to share:

a small discovery
a mistake that taught a lesson
a shortcut or improvement
a concern others might face soon These small insights, shared consistently, prevent repeated mistakes and keep everyone aligned.

When One Teaches, Everyone Grows

While daily sharing is important, dedicated knowledge-sharing sessions are even more powerful. Internal training sessions, demos, or short presentations allow one team member to share deeper expertise with the rest of the team.
They spread ownership, reduce dependency on single experts, and raise the overall level of the group.
Teaching isn't a distraction from work, it is part of the work.

Pair Programming as a Knowledge Bridge

Pair programming is one of the most effective tools for sharing knowledge and experience. The team members work together, share knowledge and learn together, keep team members:

communicating constantly
learning different approaches
understanding parts of the system they wouldn't touch alone More than a coding technique, pair programming is a collaboration practice that spreads context and builds trust.

Building a Culture of Openness

Knowledge sharing only works when people feel safe to speak, ask, and admit they don't know something.
Teams grow faster when learning is celebrated, and mistakes are treated as feedback, not failure.
When curiosity is valued over ego, knowledge flows naturally.

Final Thought

Knowledge grows when it's shared.
Teams don't become strong because a few people know everything. They become strong when everyone knows enough to move forward together.
The best developers aren't the ones who know the most, they're the ones who help others know more.

✅ That's all, folks!

💬 Let's Connect

Have any questions, suggestions for improvement, or just want to share your thoughts?

Feel free to leave a comment here, or get in touch with me directly on LinkedIn — I’d love to connect!

Moving Smarter, Not Faster: How Organization Shapes Great Teams

Renan Martins — Tue, 25 Nov 2025 15:00:00 +0000

After years of working with different teams, one pattern became impossible to ignore: the teams that consistently delivered weren't the ones rushing or pushing harder.
They were the ones who knew how to plan, prioritize, and bring clarity to chaos.

The best teams don't move faster, they move smarter.

In every project I've seen, chaos doesn't come from bad intentions or weak skills. It comes from a lack of organization.

When a Team Has Everything, Except Organization

A few years ago, I joined a team that, at first glance, had everything going for them.
They communicated well, they were technically strong, and they genuinely cared about the product. Even though, there was something was deeply wrong: they were drowning.

There was an almost one-year backlog of client customization requests, a full year of work waiting in line:

It wasn't because the team was slow or inefficient.
It wasn't because the requests were too complex.
And, it definitely wasn't because the developers lacked skill.

The real issue was simpler, but more damaging: they had no structure to support their effort.

Code organization was inconsistent and their processes weren't standardized.
There was no predictable way to analyze, prioritize, or break down tasks, and because everything felt urgent, no one had the space to step back and ask: "Why are we always behind?"

They weren't failing because of performance. They were failing because the chaos around them made improvement impossible.

Rebuilding Structure From the Inside Out

When I moved into a leadership role, I didn't start by pushing the team to work harder or faster, actually, they were already doing that.

Instead, we focused on the fundamentals:

Reorganizing parts of the codebase.
Simplifying and clarifying process flows.
Standardizing how requests were analyzed and sized.
Reducing invisible work by making everything visible.
Creating feedback loops to adjust our structure continuously.

We didn't introduce anything radical, just organization, clarity, and repeatable habits.
That changed everything.

One Year Later: Completely Different Scenario

Within a year, the transformation was huge.

The backlog that once stretched over 12 months had shrunk to less than 3 months, and it kept trending down toward 1 month, a level the team once thought impossible.

We did it without hiring more people, without major rewrites, and without extra pressure.

The difference was structure.
The difference was organization.
The difference was finally giving the team the breathing room to think instead of just reacting.

What Good Organization Actually Looks Like

Good organization isn't about rigid processes, fancy tools, or adding layers of bureaucracy.
It's about building clarity, predictability, and shared understanding so the team can focus on what matters: solving real problems.

Here's what it really looks like inside a healthy, well-organized team

Clear Priorities

Everyone knows what matters most and why.
No guessing, no mixed signals.

Visible Work

Tasks, blockers, and progress are transparent.
If work is invisible, it becomes unmanageable.

Simple Processes

Not heavy frameworks, just small, consistent habits the team actually follows.

Predictable Code Structure

Clean, organized code makes planning, reviewing, and improving easier for everyone.

Space to Think

When the team isn't drowning, they can improve, not just react.

Final Thought

Organization isn't about slowing teams down.
It's what frees them to move intelligently, collaboratively, and confidently. Because at the end of the day:

Teams don't become great by moving faster, they become great by moving smarter!

This is what transforms effort into progress, and chaos into momentum.

✅ That’s all, folks!

💬 Let’s Connect

Have any questions, suggestions for improvement, or just want to share your thoughts?

Feel free to leave a comment here, or get in touch with me directly on LinkedIn — I’d love to connect!

Talk Early, Fail Less: How Communication Builds Great Teams

Renan Martins — Tue, 11 Nov 2025 15:00:00 +0000

Every great product starts with people, not code.
This post kicks off my new series People Over Pixels, where I share the soft skills that I believe are more important than any framework, syntax, or architecture.
After years of working in different teams, I’ve realized that the success of a product depends less on how we code, and more on how we communicate.

When One Missing Conversation Costs Million of Dollars

In 1999, NASA lost the Mars Climate Orbiter, a $125 million spacecraft. Not because of bad hardware, or a complex bug, but because two brilliant teams weren’t aligned. One used imperial units. The other used metric.
A single misunderstanding destroyed years of work and one of the most advanced spacecraft ever built [1].

That story stuck with me because it shows something simple yet profound:

Even the best engineers fail when they stop talking the same language.

Why Teams Need to Talk

The best teams I’ve worked with didn’t avoid problems, they talked about them early. They didn’t guess what others meant, they asked. They didn’t hide mistakes, they shared them before they grew.
Communication isn’t about meetings or documentation. It’s about creating a shared understanding, so everyone moves in the same direction.

The Power of Asking Questions

I used to stay quiet when I wasn’t 100% sure about something. I thought asking too many questions would make me look less experienced, but the truth is the opposite.
The people who ask questions make everyone smarter. They catch assumptions, expose risks, and help the team think more clearly.

The best developers aren’t the ones who always know the answer, they’re the ones who make it safe for everyone to ask the hard questions.

Lessons from Toyota: Communication as Quality

Toyota’s production system is famous for one rule: any worker on the line can pull the andon cord to stop production if they see a problem.
It doesn’t matter who you are, everyone is empowered to speak up. That culture of openness made Toyota one of the most consistent, high-quality manufacturers in the world.
In software, "pulling the andon cord" means saying:

"I think we might have a problem here."
"I’m not sure I understood this requirement."
"Can we discuss another approach?"

That’s how teams build quality, not just in their code, but in their relationships.

Communication Is a Force Multiplier

Good communication turns individual effort into collective success. It’s how teams stay aligned, fix problems faster, and build trust over time.
When people talk, they discover solutions no one could find alone. When they stay silent, even the best code can’t save them.

Final Thought

Great teams aren’t made of the most talented individuals, they’re made of people who talk, listen, and learn together. So, if you want your next project to succeed, don’t just focus on writing perfect code.

Focus on creating conversations that lead to better code, because in the end:

Teams that talk early, fail less, and build more.

References

[1] Simscale - When NASA Lost a Spacecraft Due to a Metric Math Mistake

✅ That’s all, folks!

💬 Let’s Connect

Have any questions, suggestions for improvement, or just want to share your thoughts?

Feel free to leave a comment here, or get in touch with me directly on LinkedIn — I’d love to connect!

Teaching My Team How to Build LINQ from Scratch

Renan Martins — Tue, 04 Nov 2025 15:00:00 +0000

After weeks exploring IEnumerable, yield return, and xUnit, we’ve reached the final step of our journey: building our own LINQ methods.

This is the story of how I used this project to teach my team C# fundamentals and remove the illusion that LINQ is “something magical.”

It’s not magic, it’s just beautifully structured C# code.

Why I Built This Project for My Team

As a team lead, I noticed some developers using LINQ daily without really knowing how it worked.

So, I decided to create a simple project to teach them how to implement LINQ-like methods from scratch.

We used everything we learned throughout this series:

IEnumerable<T> and iteration
Extension methods
yield return and deferred execution
Unit testing with xUnit

The complete project is available on GitHub:

👉 github.com/reenanms/My.Linq

Using the Test Project from the Previous Article

In the last article, we wrote tests for Where and Any.

Now it’s time to make those tests pass with your own implamentation!

We’ll create a new C# project called MyLinq and add a class LinqExtensions with empty methods.

public static class LinqExtensions
{
    public static IEnumerable<T> Where<T>(this IEnumerable<T> list, Func<T, bool> filter)
    {
        throw new NotImplementedException();
    }

    public static bool Any<T>(this IEnumerable<T> list)
    {
        throw new NotImplementedException();
    }

    public static bool Any<T>(this IEnumerable<T> list, Func<T, bool> filter)
    {
        throw new NotImplementedException();
    }
}

Then, we’ll update our test project to reference this one.

Finally, replace this line in the tests:

using System.Linq;

with:

using MyLinq;

Now your tests will target your implementation instead of the real LINQ.

Implementing `.Where()`

Here’s our custom version of the Where method:

public static IEnumerable<T> Where<T>(this IEnumerable<T> list, Func<T, bool> filter)
{
    foreach (var item in list)
    {
        if (filter(item))
            yield return item;
    }
}

This method uses yield return to generate results one by one, the same concept used internally by LINQ.
Thanks to deferred execution, no new list is created in memory; items are returned as needed.
Run your tests, and the Where tests from the previous article should now pass ✅

Implementing `.Any()`

Now let’s implement Any.
We’ll write two versions: one without parameters, and one that takes a condition.

public static bool Any<T>(this IEnumerable<T> list)
{
    foreach (var _ in list)
        return true;
    return false;
}

public static bool Any<T>(this IEnumerable<T> list, Func<T, bool> filter)
{
    foreach (var item in list)
    {
        if (filter(item))
            return true;
    }

    return false;
}

The first one checks if any element exists, while the second checks if any element matches a given condition.
Simple, efficient, and clear.

Running the Tests

Now, run all the tests again:

dotnet test

If everything is set up correctly, all tests should pass 🎉

This moment is satisfying. Watching green check marks appear knowing you just rebuilt core LINQ behavior from scratch.

What The Team Learned

When we finished this project, something changed in how my team approached C#.
They realized:

LINQ isn’t “doing magic”, it’s just well-written extension methods.
IEnumerable<T> and yield return are extremely powerful tools.
Writing tests first helps clarify logic and prevents mistakes.

It became one of our favorite learning sessions as a team.

Wrapping Up the Series

This article closes the From Blank to LINQ Mastery series, a journey that started when I blanked in an interview question about LINQ 😅
Now, we’ve gone full circle: understanding it, rebuilding it, and teaching it.

If you haven’t seen the previous articles, you can start from the beginning here:

When I Went Blank in an Interview – and What I Learned About LINQ
Understanding IEnumerable in C#: The Foundation of LINQ
How Extension Methods Unlock LINQ’s Magic in C#
C#’s Hidden Gem: How Yield Return Makes Iterators Simple
Unit Testing Our First LINQ-like Methods in C#
Teaching My Team How to Build LINQ from Scratch

✅ That’s all, folks!

💬 Let’s Connect

Have any questions, suggestions for improvement, or just want to share your thoughts?

Feel free to leave a comment here, or get in touch with me directly on LinkedIn — I’d love to connect!

Unit Testing Our First LINQ-like Methods in C#

Renan Martins — Tue, 28 Oct 2025 14:30:00 +0000

Before we start writing our own LINQ methods, we’ll take a quick step back to prepare a strong foundation: unit testing.

In this article, we’ll use xUnit to define how our LINQ-like methods should behave before we even implement them.

This approach will make our next article — where we start coding Where and Any — much easier to understand and validate.

Why Write Tests First?

We’ve already learned about IEnumerable, extension methods, and yield return. Now it’s time to put that knowledge to work.

But instead of jumping directly into coding, we’ll describe how our methods are supposed to behave — using unit tests.

Writing tests first gives us:

A clear definition of what each method should do.
Confidence that our implementation works.
Easier debugging later, since failing tests tell us exactly what’s wrong.

This is the spirit of Test-Driven Development (TDD) — write tests first, make them fail, then implement the logic until they pass.

Setting Up xUnit

We’ll use xUnit, a popular and lightweight testing framework for .NET.

To create a new test project, open the terminal and run:

dotnet new xunit -n MyLinq.Tests

Then, add the reference packages to the project:

cd MyLinq.Tests
dotnet add MyLinq.Tests.csproj package xunit
dotnet add MyLinq.Tests.csproj package xunit.runner.visualstudio
dotnet add MyLinq.Tests.csproj package Microsoft.NET.Test.Sdk

Now, we can start writing tests inside the MyLinq.Tests project.

Each test class should focus on a single area of your code, for example, we’ll start with Where and Any.

Writing Our First Test: `Where`

Let’s describe what we expect our future Where method to do:

public void WhereOfArrayOfNumbers()
{
    var myListOfNumbers = new[] { 1, 2, 3, 4 ,5 , 6, 7, 8, 9 };

    var myResultAfterFilter = myListOfNumbers.Where(i => i <= 5);

    var myListOfExpectNumbers = new[] { 1, 2, 3, 4, 5 };
    Assert.Equal(myListOfExpectNumbers, myResultAfterFilter);
}

We’re calling the method Where, which is a LINQ method, that in the future we are going to replace for our own.

Testing the `Any` Method

Now let’s define tests for another common LINQ method: Any.

[Fact]
public void AnyOfEmptyArray()
{
    var myListOfNumbers = new int[] {};

    var myResult = myListOfNumbers.Any();

    Assert.False(myResult);
}

[Fact]
public void AnyOfArrayOfNumbers()
{
    var myListOfNumbers = new[] { 1 };

    var myResult = myListOfNumbers.Any();

    Assert.True(myResult);
}

[Fact]
public void AnyOfArrayOfNumbersWithFilterLessThenFive()
{
    var myListOfNumbers = new[] { 5, 6, 7 };

    var myResult = myListOfNumbers.Any(i => i < 5);

    Assert.False(myResult);
}

[Fact]
public void AnyOfArrayOfNumbersWithFilterMoreThenFive()
{
    var myListOfNumbers = new[] { 5, 6, 7 };

    var myResult = myListOfNumbers.Any(i => i > 5);

    Assert.True(myResult);
}

These tests give us a clear idea of what we expect from the implementation we’ll build next.

What’s Next

In the next article, we’ll finally implement our own methods from scratch. The methods will have the same name as LINQ, and we are going to point the test to the new namespace (intead System.Linq).

By starting with tests first, we’re setting the stage for a more predictable and maintainable LINQ-like library.

Key Takeaways

Write tests before implementation to define expected behavior.
xUnit makes it easy to structure and automate C# tests.
We’re now ready to implement our own LINQ methods!

✅ That’s all, folks!

C#’s Hidden Gem: How Yield Return Makes Iterators Simple

Renan Martins — Tue, 21 Oct 2025 14:30:00 +0000

If you have ever tried to write an iterator manually, you know it can be painful. You need to manage indexes, track conditions, and build temporary lists.
This article continues my series From Blank to LINQ Mastery, exploring one of the simplest and most powerful features in C#, yield return.

What Are Iterators

An iterator is a method or object that lets you go through a sequence one element at a time.
In C#, it is any method that returns IEnumerable<T>.
The foreach loop uses this mechanism internally to iterate over data.

The Old Way (Without yield return)

public static IEnumerable<int> GetEvenNumbers(List<int> numbers)
{
    var result = new List<int>();
    foreach (var n in numbers)
    {
        if (n % 2 == 0)
            result.Add(n);
    }
    return result;
}

This code works, but creates a new list in memory before returning the result.

The Modern Way (With yield return)

public static IEnumerable<int> GetEvenNumbers(List<int> numbers)
{
    foreach (var n in numbers)
    {
        if (n % 2 == 0)
            yield return n;
    }
}

With yield return, C# automatically creates an iterator behind the scenes. Although, it's important to understand that this method behaves a little differently from what you might expect.
It does not run from start to finish in one call.
Instead, it pauses each time it returns a value and resumes from that exact point when the next element is requested.

Here is a quick example that makes this clear:

public static IEnumerable<int> SampleIterator()
{
    Console.WriteLine("Start");
    yield return 1;

    Console.WriteLine("Middle");
    yield return 2;

    Console.WriteLine("End");
}

Now we have the method returning and iteratos, let's call it to see what happens when you iterate over it:

var sequence = SampleIterator();
Console.WriteLine("Before iteration");

foreach (var n in sequence)
    Console.WriteLine($"Value: {n}");

Console.WriteLine("After iteration");

Let's check the output:

Before iteration
Start
Value: 1
Middle
Value: 2
End
After iteration

Notice that function is not executed in its call. The method stops and resumes multiple times. Execution moves step by step, each time MoveNext() is called in the background.
This is known as deferred execution, and it is the key to how LINQ operators process data lazily and efficiently.

Adding Control with yield break

Sometimes you may want to stop the iteration early.
That is where yield break shows up.

public static IEnumerable<int> GetFirstThreeEvenNumbers(List<int> numbers)
{
    int count = 0;
    foreach (var n in numbers)
    {
        if (n % 2 == 0)
        {
            yield return n;
            count++;
        }

        if (count == 3)
            yield break;
    }
}

This stops the sequence once three even numbers have been returned.
No extra memory or complex logic required.

⚠️ Tip: Be Careful with Database Iteration

When using yield return with data that comes from a database, remember that the database connection must remain open while the iterator is being read.
If you close or dispose the connection before finishing the iteration, you will get exceptions or incomplete results.
A good practice is to materialize the results (for example, with .ToList()) before the connection is closed, unless you have full control over when and how the data is consumed.

Why It Matters for LINQ

Most LINQ methods such as .Where(), .Select(), and .Take() use yield return internally.
That is how LINQ can process data efficiently, creating values only when they are actually needed.

Key Takeaways

yield return simplifies iteration logic.
It supports deferred execution, generating elements on demand.
It is the foundation for how LINQ operators work behind the scenes.
Be careful when combining it with database queries that depend on open connections.

✅ That’s all, folks!

How Extension Methods Unlock LINQ’s Magic in C#

Renan Martins — Tue, 14 Oct 2025 14:30:00 +0000

LINQ feels like magic: you call .Where() on a list, and it just works. The secret? Extension methods.

What are Extension Methods?

They allow us to “add” methods to existing classes without modifying them.

To create one, you need:

A static class to contain your extensions.
A static method inside that class.
The this keyword before the first parameter tells the compiler which type you’re extending.
The namespace defines the scope, it'll apply just for the defined, to use in another using statement must be used.

Adding Behavior to Strings

public static class StringExtensions
{
    public static bool IsCapitalized(this string input)
    {
        if (string.IsNullOrEmpty(input)) return false;
        return char.IsUpper(input[0]);
    }
}

Console.WriteLine("Hello".IsCapitalized()); // True
Console.WriteLine("world".IsCapitalized()); // False

This shows the basic idea: we added a new method to string, even though we don’t own the string class.

Making Collections Smarter with Generics

Extension methods get really useful when working with collections. Let’s make one that works with any type and mimics the idea of LINQ’s Where.

public static class EnumerableExtensions
{
    public static IEnumerable<T> WhereNotNull<T>(this IEnumerable<T?> source) where T : class
    {
        var result = new List<T>();
        foreach (var item in source)
        {
            if (item != null)
                result.Add(item);
        }
        return result;
    }
}

var names = new List<string?> { "Alice", null, "Bob", null, "Charlie" };
var filtered = names.WhereNotNull();
Console.WriteLine(string.Join(", ", filtered)); 
// Output: Alice, Bob, Charlie

Here we combined generics (T) with IEnumerable<T>:

It works with any reference type.
It feels just like a LINQ method (WhereNotNull is similar to Where(x => x != null)).

Key Takeaways

Extension methods let you “teach” existing types new tricks.
They can be simple (string.IsCapitalized()) or collection-based (WhereNotNull<T>()).
Always remember: static class + static method + this keyword + correct namespace = extension method.
LINQ itself is just a big set of extension methods for IEnumerable<T>.

✅ That’s all, folks!

Understanding IEnumerable in C#: The Foundation of LINQ

Renan Martins — Tue, 07 Oct 2025 14:30:00 +0000

If you’ve ever used a foreach loop in C#, you’ve already been using IEnumerable.

It’s one of the most fundamental interfaces in .NET and forms the foundation of LINQ.

What is IEnumerable?

IEnumerable<T> represents a sequence of elements that you can iterate over, one by one.

It powers the foreach loop.

var numbers = new List<int> { 1, 2, 3 };

foreach (var n in numbers)
{
    Console.WriteLine(n);
}

Behind the scenes, foreach calls GetEnumerator(), which returns an iterator.

The Interface Definition

Here’s the simplified definition of IEnumerable<T>:

public interface IEnumerable<out T>
{
    IEnumerator<T> GetEnumerator();
}

It’s surprisingly simple. It just promises that any type implementing it can return an IEnumerator<T>.

And what’s IEnumerator<T>? It’s another interface that knows how to move through a sequence:

public interface IEnumerator<T> : IDisposable
{
    T Current { get; }
    bool MoveNext();
    void Reset(); // rarely used in practice
}

Iterating Without `foreach`

Since foreach is just syntactic shortcut, you can do the same manually:

var numbers = new List<int> { 1, 2, 3 };
var enumerator = numbers.GetEnumerator();

while (enumerator.MoveNext())
{
    var current = enumerator.Current;
    Console.WriteLine(current);
}

Custom Implementation Example

You can also implement IEnumerable<T> yourself.

Here’s a simple example that generates even numbers up to a maximum value:

public class EvenNumbers(int last) : IEnumerable<int>
{
    public class EvenNumber(int last) : IEnumerator<int>
    {
        private int _current = -2;

        public bool MoveNext()
        {
            _current += 2;
            return _current <= last;
        }

        public void Reset() => _current = -2;
        int IEnumerator<int>.Current => _current;
        object? System.Collections.IEnumerator.Current => _current;
        public void Dispose() { }
    }

    public IEnumerator<int> GetEnumerator() => new EvenNumber(last);
    System.Collections.IEnumerator System.Collections.IEnumerable.GetEnumerator() => this.GetEnumerator();
}

Usage:

var evens = new EvenNumbers(10);

foreach (var e in evens)
    Console.WriteLine(e);
// Output: 0, 2, 4, 6, 8, 10

Notice that the _current always starts in an invalid position and has the right value after the first call of MoveNext().

Why is it Important?

LINQ methods like .Where(), .Select(), and .OrderBy() all extend IEnumerable<T>.

Without it, LINQ wouldn’t exist.

Example:

var numbers = Enumerable.Range(1, 5);  
var squared = numbers.Select(x => x * x);

Console.WriteLine(string.Join(", ", squared));
// Output: 1, 4, 9, 16, 25

Deferred Execution

A powerful feature of IEnumerable<T> is deferred execution.

LINQ queries aren’t run immediately, they’re only executed when you iterate.

var numbers = Enumerable.Range(1, 5);
var query = numbers.Where(n => n % 2 == 0);

// Nothing happens yet!

foreach (var n in query)
    Console.WriteLine(n); // Execution happens here

This allows efficient chaining of operations without unnecessary work.

Performance Notes

IEnumerable<T> only supports forward iteration. You can’t access items by index or know the count without iterating.
For random access or collection size, use ICollection<T> or IList<T>.
Best suited for streaming data and large sequences where you don’t want everything in memory at once.

Key Takeaways

IEnumerable<T> defines the contract for iteration in C#.
It powers foreach and enables LINQ.
IEnumerator<T> drives iteration with MoveNext() and Current.
LINQ queries on IEnumerable<T> use deferred execution.
For advanced operations like indexing, prefer IList<T> or ICollection<T>.

✅ That’s all, folks!

When I Went Blank in an Interview – and What I Learned About LINQ

Renan Martins — Tue, 30 Sep 2025 14:30:00 +0000

Recently, I had a job interview where I was asked a very simple question:
“What is LINQ?”

Even though I know the answer, my mind just froze. For some reason, the only word that came to me was “link”.

After the interview, I laughed at myself — but it also inspired me to write this short article, not only to reinforce the concept for myself but also to help other beginners in .NET who might face the same question.

What is LINQ in .NET?

LINQ stands for Language Integrated Query.
It is a feature of C# and .NET that allows developers to query and manipulate data in a consistent and expressive way, directly inside the programming language.

Why is LINQ important?

Before LINQ, working with different data sources (lists, XML, databases, etc.) required completely different approaches.
LINQ simplifies this by providing a unified syntax to query data, making code easier to read, write, and maintain.

A Simple Example

Imagine you want to filter even numbers from a list.

Query syntax:

var numbers = new List<int> { 1, 2, 3, 4, 5, 6 };

// LINQ query syntax
var evens = from n in numbers
            where n % 2 == 0
            select n;

foreach (var e in evens)
{
    Console.WriteLine(e);
}

Method syntax (more common in real-world projects, and also my preference):

var evens = numbers.Where(n => n % 2 == 0);

More Usage Examples

LINQ is not just about filtering. Here are some other powerful operators you’ll use often:

Count

var count = numbers.Count(); // 6

Any

var hasEven = numbers.Any(n => n % 2 == 0); // true

Where

var odds = numbers.Where(n => n % 2 != 0); // 1, 3, 5

OrderBy / OrderByDescending

var ordered = numbers.OrderBy(n => n);     // 1, 2, 3, 4, 5, 6
var desc = numbers.OrderByDescending(n => n); // 6, 5, 4, 3, 2, 1

Select

var squares = numbers.Select(n => n * n); // 1, 4, 9, 16, 25, 36

Combining Operators

var result = numbers
    .Where(n => n % 2 == 0)
    .OrderBy(n => n)
    .Select(n => $"Even number: {n}");

foreach (var item in result)
{
    Console.WriteLine(item);
}

Where Can You Use LINQ?

LINQ can be used in many contexts:

In-memory collections (List, Array, etc.) → LINQ to Objects
Databases (via Entity Framework) → LINQ to Entities
XML files → LINQ to XML
And more

Upcoming Articles in This Series

This article is just the beginning! I’ll be publishing more deep dives into how LINQ works under the hood and how we can even build our own LINQ-like library. Stay tuned for:

When I Went Blank in an Interview – and What I Learned About LINQ
Understanding IEnumerable in C#: The Foundation of LINQ
How Extension Methods Unlock LINQ’s Magic in C#
C#’s Hidden Gem: How Yield Return Makes Iterators Simple
Unit Testing Our First LINQ-like Methods in C#
Teaching My Team How to Build LINQ from Scratch

Final Thoughts

LINQ is one of the most powerful features in C#. It makes data querying integrated, type-safe, and expressive.

So, if someone asks me again in an interview, I’ll have a much clearer answer ready — and hopefully no more blanks!

💡 Interview-ready answer:

LINQ (Language Integrated Query) is a feature in .NET that provides a consistent and type-safe way to query and manipulate data from different sources (collections, databases, XML) directly within C#.

✅ That’s all, folks!

💬 Let’s Connect

Have any questions, suggestions for improvement, or just want to share your thoughts?

Feel free to leave a comment here, or get in touch with me directly on LinkedIn — I’d love to connect!

DEV Community: Renan Martins

Resilience Through Adaptability: Solving the Problem, Not the Process

Flexibility Is Strength, Not Chaos

The Pragmatic Engineer’s Dilemma: Speed vs. Perfection

What Flexibility Looks Like in Practice

The Cost of Rigidity

Balance Between Stability and Adaptability

Final Thought

Knowledge Sharing: Strong Teams Share What They Know

Why Knowledge Sharing Really Matters

Daily Sharing Builds Alignment

When One Teaches, Everyone Grows

Pair Programming as a Knowledge Bridge

Building a Culture of Openness

Final Thought

Moving Smarter, Not Faster: How Organization Shapes Great Teams

When a Team Has Everything, Except Organization

Rebuilding Structure From the Inside Out

One Year Later: Completely Different Scenario

What Good Organization Actually Looks Like

Clear Priorities

Visible Work

Simple Processes

Predictable Code Structure

Space to Think

Final Thought

Talk Early, Fail Less: How Communication Builds Great Teams

When One Missing Conversation Costs Million of Dollars

Why Teams Need to Talk

The Power of Asking Questions

Lessons from Toyota: Communication as Quality

Communication Is a Force Multiplier

Final Thought

References

Teaching My Team How to Build LINQ from Scratch

Why I Built This Project for My Team

Using the Test Project from the Previous Article

Implementing .Where()

Implementing .Any()

Running the Tests

What The Team Learned

Wrapping Up the Series

Unit Testing Our First LINQ-like Methods in C#

Why Write Tests First?

Setting Up xUnit

Writing Our First Test: Where

Testing the Any Method

What’s Next

Key Takeaways

C#’s Hidden Gem: How Yield Return Makes Iterators Simple

What Are Iterators

The Old Way (Without yield return)

The Modern Way (With yield return)

Adding Control with yield break

⚠️ Tip: Be Careful with Database Iteration

Why It Matters for LINQ

Key Takeaways

How Extension Methods Unlock LINQ’s Magic in C#

What are Extension Methods?

Adding Behavior to Strings

Making Collections Smarter with Generics

Key Takeaways

Understanding IEnumerable in C#: The Foundation of LINQ

What is IEnumerable?

The Interface Definition

Iterating Without foreach

Custom Implementation Example

Why is it Important?

Deferred Execution

Performance Notes

Key Takeaways

When I Went Blank in an Interview – and What I Learned About LINQ

What is LINQ in .NET?

Why is LINQ important?

A Simple Example

More Usage Examples

Count

Any

Where

OrderBy / OrderByDescending

Implementing `.Where()`

Implementing `.Any()`

Writing Our First Test: `Where`

Testing the `Any` Method

Iterating Without `foreach`