Forem: Rasheed K Mozaffar

My Best Advice as a Software Engineer

Rasheed K Mozaffar — Mon, 19 Jan 2026 00:23:38 +0000

Hello There 👋🏻

My fellow developers, coders, and amazing engineers, welcome to this post where I wanted to share the best piece of advice I've gathered throughout my career as a junior software engineer trying to level up. Without talking much, let's get to it.

Introduction

I have made a post before about my experience as an entry-level (junior) software enginee, where I shared some highlights and things I've learned during that period from my day-to-day job, and now that I've been getting myself into many different things in my work, I started learning something that I wasn't aware of when I first wrote that post.

I started my job a year and 6 months ago, with every one on my job being way more experienced than I was given it was my first ever professional job, and working in a startup that's in the field of cybersecurity and security services, everything was fast moving and it wasn't just about the technical gains I would have to make, but also wrap my head around a domain I'm not familiar with at all.

Over time, I began learning some basic things to understand the domain, and luckily, I didn't have to worry much about the technical things, as my C# and .NET familiarity helped me a lot, so I had spare time to ask other people and learn from them about concepts that at the beginning were mysterious.

In startups, the fun thing is code is always being prepared and shipped, unlike large corporates where change is slow, and on big features, the seniors would discuss architecture along with the architect and stakeholders, at least that's how it is for us. When I wanted to really improve, I began pushing myself into those meetings even to listen to what's being discussed, and that was the eye-opening turning point.

Don't just ask "What should I do?"

This is my best advice, literally. Hear me out.
One time in the discussion, everything was being laid out from the Product Requirements Document and design mockups. I didn't understand what the best solution was, but I knew I wanted to take a big part of the feature.
So I reached out to the team and took ownership of the feature. It wasn't super high-priority, so I had the time. I started researching possible solutions, writing things on paper, and making simple flows with FigJam until I came up with my final solution. I then pitched it to the team, it was approved, and then I started my implementation.
It turned out to be a success and admittedly, some tiny bugs showed up, which I was able to resolve easily. In another breaking feature, I did the same, approached the problem by thinking of solutions, writing things down and then pitching out my idea. At this moment, I wasn't just asking What should I do? or What should I work on?, I was asking How would I solve this? and What works and what not?, What are the trade-offs of this over that?. Now looking back at my decision to not just take a task and work on it, to rather own an entire feature from initial solution drafting to production, I can say it was the best decision in terms of growth and learning.

Moral of the story

If you want to really level up in whatever you do, don't just limit yourself to being someone who just executes something, like take a task and just finish it, ask questions, go explore, and ponder on how to solve problems, because the moment you stop asking What should I work on?, you open your mind to a bunch of ideas and ways of doing things that you never knew existed, you simply become a problem solver, you see a problem and realize, oh, we can do this this and that, oh, this can be solved this way, and we have these options to use as a solution.
I hope this experience I just shared benefited you even in the slightest means possible!

Thanks for reading

Pattern Matching in C#: The Starters Guide

Rasheed K Mozaffar — Tue, 23 Dec 2025 15:41:29 +0000

Hey there! 👋🏻

If you've been coding in C# for a while, you've probably used the traditional if-else statements and the classic switch statement to handle different conditions in your code. But did you know that C# has evolved significantly in this area? Pattern matching is one of those powerful features that makes your code cleaner, more readable, and honestly, more fun to write!

In this post, we're going to explore pattern matching in C#, and I'll show you how it can transform your conditional logic from verbose and repetitive to concise and elegant.

What is Pattern Matching? 🤔

Pattern matching is a feature in C# that allows you to test if a value has a certain "shape" and extract information from it at the same time. Instead of writing multiple if statements to check types, values, or properties, you can express these checks more naturally and in fewer lines of code.

Think of it as a smarter, more expressive way to ask questions about your data.

The Classic Switch Statement (The Old Way) 🕰️

Before we dive into pattern matching, let's look at how we used to handle different cases with the traditional switch statement:

public string GetAnimalSound(string animal)
{
    switch (animal)
    {
        case "Dog":
            return "Woof!";
        case "Cat":
            return "Meow!";
        case "Cow":
            return "Moo!";
        default:
            return "Unknown sound";
    }
}

This works, but it's quite verbose, especially when you need to handle more complex scenarios. Now let's see how pattern matching makes this better!

Switch Expressions (The New Way) ✨

C# introduced switch expressions, which are a more concise way to write switch statements. Here's the same code rewritten using a switch expression:

public string GetAnimalSound(string animal) => animal switch
{
    "Dog" => "Woof!",
    "Cat" => "Meow!",
    "Cow" => "Moo!",
    _ => "Unknown sound"
};

Much cleaner, right? Notice how we got rid of the case, return, and break keywords. The _ at the end is the discard pattern, which acts like the default case.

Type Patterns 🎯

One of the most useful aspects of pattern matching is checking the type of an object and extracting it in one go. Before pattern matching, you'd have to do something like this:

// The old way
public void ProcessPayment(object payment)
{
    if (payment is CreditCard)
    {
        var creditCard = (CreditCard)payment;
        Console.WriteLine($"Processing credit card ending in {creditCard.LastFourDigits}");
    }
    else if (payment is PayPal)
    {
        var paypal = (PayPal)payment;
        Console.WriteLine($"Processing PayPal payment for {paypal.Email}");
    }
}

With pattern matching, you can check the type and declare a variable in one line:

// The new way
public void ProcessPayment(object payment)
{
    if (payment is CreditCard card)
    {
        Console.WriteLine($"Processing credit card ending in {card.LastFourDigits}");
    }
    else if (payment is PayPal paypal)
    {
        Console.WriteLine($"Processing PayPal payment for {paypal.Email}");
    }
}

Even better, you can use a switch expression for this:

public string ProcessPayment(object payment) => payment switch
{
    CreditCard card => $"Processing credit card ending in {card.LastFourDigits}",
    PayPal paypal => $"Processing PayPal payment for {paypal.Email}",
    BankTransfer bank => $"Processing bank transfer from {bank.AccountNumber}",
    _ => "Unknown payment method"
};

Property Patterns 🔍

Property patterns let you match based on the properties of an object. This is incredibly useful when you want to make decisions based on the state of an object.

Let's say we have a Person class and we want to determine if someone is eligible for a senior discount:

public record Person(string Name, int Age, string Country);

public bool IsEligibleForSeniorDiscount(Person person) => person switch
{
    { Age: >= 65, Country: "USA" } => true,
    { Age: >= 60, Country: "UK" } => true,
    { Age: >= 67, Country: "Germany" } => true,
    _ => false
};

You can even combine multiple conditions:

public string GetTicketPrice(Person person) => person switch
{
    { Age: < 12 } => "Child ticket: $5",
    { Age: >= 12 and < 18 } => "Teen ticket: $8",
    { Age: >= 18 and < 65 } => "Adult ticket: $12",
    { Age: >= 65 } => "Senior ticket: $6",
    _ => "Unknown"
};

Relational Patterns 📊

Relational patterns allow you to use comparison operators like <, >, <=, and >= directly in your patterns. This makes range checking much cleaner:

public string GetGrade(int score) => score switch
{
    >= 90 => "A",
    >= 80 => "B",
    >= 70 => "C",
    >= 60 => "D",
    _ => "F"
};

Compare this to the traditional approach:

// The old way
public string GetGrade(int score)
{
    if (score >= 90)
        return "A";
    else if (score >= 80)
        return "B";
    else if (score >= 70)
        return "C";
    else if (score >= 60)
        return "D";
    else
        return "F";
}

The pattern matching version is not only shorter but also more readable!

Logical Patterns (and, or, not) 🧮

You can combine patterns using logical operators to create more complex conditions:

public string CheckWeather(int temperature) => temperature switch
{
    < 0 => "Freezing!",
    >= 0 and < 15 => "Cold",
    >= 15 and < 25 => "Mild",
    >= 25 and < 35 => "Warm",
    >= 35 => "Hot!",
    _ => "Unknown"
};

public bool IsWeekend(DayOfWeek day) => day switch
{
    DayOfWeek.Saturday or DayOfWeek.Sunday => true,
    _ => false
};

public bool IsValidAge(int age) => age switch
{
    >= 0 and <= 120 => true,
    _ => false
};

Real-World Example 🌍

Let's put it all together with a practical example. Imagine you're building an e-commerce system and need to calculate shipping costs based on multiple factors:

public record Order(decimal TotalAmount, string Country, bool IsPrime, int Weight);

public decimal CalculateShipping(Order order) => order switch
{
    { IsPrime: true } => 0m,
    { Country: "USA", Weight: <= 1 } => 5m,
    { Country: "USA", Weight: > 1 and <= 5 } => 10m,
    { Country: "USA", Weight: > 5 } => 15m,
    { Country: "Canada", Weight: <= 1 } => 8m,
    { Country: "Canada", Weight: > 1 and <= 5 } => 15m,
    { Country: "Canada", Weight: > 5 } => 25m,
    { TotalAmount: >= 100 } => 0m,
    _ => 20m
};

This code is clean, easy to read, and handles multiple conditions elegantly. Try writing the same logic with traditional if-else statements, and you'll see how much more verbose it would be!

When to Use Pattern Matching ⚙️

Pattern matching shines when you need to:

Check types and extract values at the same time
Make decisions based on object properties
Handle multiple conditions with different ranges or values
Replace long chains of if-else statements
Make your code more expressive and readable

Conclusion ✅

Pattern matching in C# is a powerful feature that makes your code more concise and expressive. We've covered switch expressions, type patterns, property patterns, relational patterns, and logical patterns. Each of these gives you a new tool to write cleaner, more maintainable code.

The best way to get comfortable with pattern matching is to start using it in your projects. Next time you're writing a switch statement or a long chain of if-else conditions, try refactoring it with pattern matching and see the difference!

I hope you learned something new from this post!

Thanks for reading! 👋🏻

Having Issues Installing Visual Studio Extensions on ARM Devices? Do this

Rasheed K Mozaffar — Thu, 18 Dec 2025 19:26:23 +0000

Howdy! 👋

If you use Visual Studio for Windows on an ARM 64 machine, and you have tried installing an extension on it, you would mostly get this error message

Note that this error doesn't occur with all extensions out there on the marketplace. However, when it does, you can easily resolve this issue with a few simple steps.

Step 1

Get yourself 7-Zip installed on your device, basically anything that allows you to open the VSIX archive file.

Step 2

Right click the VSIX file and open the archive with 7-Zip. Once you have it opened, look for a file named extension.vsixmanifest

Step 3

Once you locate the file, right click it, and then press edit, it should open up in Notepad, or anything text editor you got. Make sure you right click then select edit, don't just double click it, cause that might open it in a text editor but saving won't persist the updates on the archive itself.

Step 4

Update this value highlighted in the image below

This value initially would be set to amd64, just make it arm64 like in the image, and then close the file. Note that when you save and close, 7-Zip will prompt you to reload the archive cause its content was changed, click yes, then close it!

Step 5

No step 5 actually, just install the extension and it will work normally now!

Conclusion ✅

I've faced this issue while downloading themes and various extensions like the one I shared above, the SonarQube lint extension, and I didn't know what's the issue behind it, I was looking into the code of the extension and stumbled upon changing this value for curiosity because my device has the Snapdragon X Elite ARM-64 CPU, and it did actually work for a ton of extensions for me! So in case you came across this issue, here's your solution; Hope it's useful!

Thanks for reading 👋

How do you use AI in your work? And what's your limit?

Rasheed K Mozaffar — Wed, 26 Nov 2025 19:28:04 +0000

Hello there! 👋

AI has become an integral part of software development in the current time, with all these intelligent models and productive coding agents, it's important to keep a balance and not overuse these tools, or you have a different take on that?

Do you think we should use AI more or less in our day-to-day work, and when to limit their usage?

Share your thoughts in the comments section, and I'll go first!

Exploring the new .slnx Visual Studio Solutions Format

Rasheed K Mozaffar — Thu, 20 Nov 2025 17:02:42 +0000

Hey there! 👋🏻

If you've been keeping up with the latest updates in .NET, you might have noticed something interesting in Visual Studio 2022 version 17.13 and .NET 9: a brand new solution file format with the .slnx extension! Let's take a quick look at what this is all about.

What's the .slnx Format? 🤔

The .slnx format is Microsoft's fresh take on the solution file. Unlike the traditional .sln files we've been using for ages, this new format uses XML instead of the proprietary format that's been around since forever.

The old .sln format has served us well, but let's be honest, it's not exactly the most human-readable thing out there. The .slnx format aims to fix that!

Why Should You Care? 💡

Here's the cool part, the .slnx format is much cleaner and easier to read. If you've ever tried to manually edit a .sln file, you know it can be a bit of a nightmare. With .slnx, the XML structure makes it way more straightforward to understand what's going on.

Here's a quick comparison. This is what a traditional .sln file looks like:

Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio Version 17
VisualStudioVersion = 17.0.31903.59
MinimumVisualStudioVersion = 10.0.40219.1
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "MyApp", "MyApp\MyApp.csproj", "{12345678-1234-1234-1234-123456789012}"
EndProject

And here's what the same solution looks like in .slnx:

<Solution>
  <Project Path="MyApp\MyApp.csproj" />
</Solution>

See the difference? Much cleaner and easier to read!

How Do You Use It? 🛠️

Using the new format is pretty straightforward. When creating a new solution in Visual Studio 2022, you now have the option to create it with the .slnx extension. You can also convert your existing .sln files to .slnx by opening them in Visual Studio and saving them with the new format.

The best part? Both formats work side by side. If you're working on a team where some folks are still on older versions of Visual Studio, you can keep using .sln files without any issues.

Should You Switch? ⚖️

The .slnx format is still relatively new, so whether you should switch depends on your situation. If you're starting a fresh project and everyone on your team is using Visual Studio 2022 17.13 or later, then absolutely, give it a try! The cleaner format is definitely worth it.

However, if you're working on an existing project or with team members on older versions, you might want to stick with .sln for now to avoid compatibility issues.

Conclusion ✅

The .slnx format is a welcome improvement that makes solution files more readable and easier to work with. It's a small change, but one that can make a noticeable difference in your daily development workflow. As the format matures and becomes more widely adopted, we'll likely see even more benefits emerge.

Give it a shot on your next project and see how you like it!

Thanks for reading! 👋🏻

Exploring Extension Blocks in .NET 10

Rasheed K Mozaffar — Thu, 20 Nov 2025 10:40:49 +0000

Hey there! 👋🏻

Just used the "Generate Image" function of Dev to generate this cover, and yes, I know it says C 14 rather than C# 14.

If you've written C# code before, there's a good chance you've come across extension methods. They've been around since C# 3.0 back in 2007, and they're pretty much everywhere in .NET—especially in LINQ. But with C# 14 and .NET 10, things just got a whole lot more interesting with the introduction of Extension Blocks, or as some folks call it, Extension Everything.

So what are extension blocks? Why should you care? And how can you use them to write cleaner, more expressive code? Let's dive in and find out!

Prerequisites 🛠️

The code examples in this article require .NET 10 and C# 14, which were officially released on November 11, 2025. If you haven't already installed .NET 10, you can download it from:

Official Download: https://dotnet.microsoft.com/download/dotnet/10.0

What's New Documentation:

With that out of the way, now we can dive in!!

A Quick Refresher on Extension Methods 🔄

Before we jump into the new stuff, let's quickly recap how extension methods work. If you've used LINQ, you've definitely used extension methods without even knowing it.

ℹ️ I did write an old post about extenion methods that contains some examples as well, which you can read here if you're interested.

Here's a classic example:

public static class StringExtensions
{
    public static bool IsEmpty(this string str)
    {
        return string.IsNullOrEmpty(str);
    }
}

The magic here is the this keyword in front of the first parameter. That's what makes this a special method that can be called as if it were an instance method on the string type:

string message = "Hello World";
if (!message.IsEmpty())
{
    Console.WriteLine(message);
}

Pretty neat, right? This has been incredibly useful for extending types you don't own, like built-in types or types from third-party libraries.

The Problem With Traditional Extension Methods 🤔

While extension methods are awesome, they've always had some limitations:

You can only extend with methods, not properties or operators
Repetitive code - if you have multiple extensions for the same type, you have to keep repeating this TypeName parameter in every method
No static extensions - you couldn't add static-like members to types
Organization issues - grouping related extensions wasn't as clean as it could be

Let's say you wanted to add an IsEmpty property to IEnumerable<T>. With traditional extension methods, you'd have to write it as a method:

// This works, but feels awkward
if (myList.IsEmpty())
{
    Console.WriteLine("List is empty");
}

Wouldn't it be nicer to write it like a property?

// This is what we really want!
if (myList.IsEmpty)
{
    Console.WriteLine("List is empty");
}

Well, C# 14 heard our prayers!

Introducing Extension Blocks 🎉

Extension blocks are the new way to define extensions in C# 14. They give you the power to extend types with not just methods, but also properties, operators, and even static members. Let me show you what this looks like.

Converting a Traditional Extension Method

Let's take our IsEmpty extension method and convert it to the new syntax:

Old way (still works):

public static class EnumerableExtensions
{
    public static bool IsEmpty(this IEnumerable source)
    {
        return !source.Any();
    }
}

New way with extension blocks:

public static class EnumerableExtensions
{
    extension(IEnumerable source)
    {
        public bool IsEmpty => !source.Any();
    }
}

Notice the differences:

We use the extension keyword followed by parentheses
The type we're extending (IEnumerable<T>) goes inside the parentheses along with a parameter name (source)
Inside the curly braces, we can define our extensions - and now it can be a property instead of a method!
We no longer need the this keyword or repeat public static for each member

The best part? From the caller's perspective, it works exactly the same way:

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

// Both of these work!
bool isEmpty1 = numbers.IsEmpty();  // Old method syntax
bool isEmpty2 = numbers.IsEmpty;    // New property syntax

Real-World Example: String Extensions 📝

Let me show you a practical example that demonstrates the power of extension blocks. Imagine you want to extend the string type with several useful utilities:

public static class StringExtensions
{
    extension(string str)
    {
        // Extension property - no parentheses needed!
        public bool IsEmpty => string.IsNullOrEmpty(str);

        // Extension property with logic
        public bool IsValidEmail => str.Contains("@") && str.Contains(".");

        // Extension method
        public string Truncate(int maxLength)
        {
            if (str.Length <= maxLength)
                return str;

            return str.Substring(0, maxLength) + "...";
        }

        // Another extension method
        public string Repeat(int count)
        {
            return string.Concat(Enumerable.Repeat(str, count));
        }
    }
}

Now look how clean the calling code becomes:

string email = "user@example.com";
string name = "Bob";
string longText = "This is a very long text that needs truncating";

// Using extension properties
if (!email.IsEmpty && email.IsValidEmail)
{
    Console.WriteLine("Valid email!");
}

// Using extension methods
Console.WriteLine(name.Repeat(3));           // BobBobBob
Console.WriteLine(longText.Truncate(20));    // This is a very lon...

See how natural that feels? No awkward parentheses on IsEmpty() and IsValidEmail() - they're actual properties now!

Multiple Extensions in One Block 🗂️

One of the coolest features of extension blocks is that you can group multiple related extensions together. This makes your code much more organized and eliminates repetition:

public static class ListExtensions
{
    extension(List list)
    {
        // Property to check if list has any items
        public bool HasItems => list.Count > 0;

        // Property to get the last item safely
        public T? LastOrDefault => list.Count > 0 ? list[^1] : default;

        // Method to add multiple items
        public void AddRange(params T[] items)
        {
            foreach (var item in items)
            {
                list.Add(item);
            }
        }

        // Method to shuffle the list
        public void Shuffle()
        {
            Random rng = new Random();
            int n = list.Count;
            while (n > 1)
            {
                n--;
                int k = rng.Next(n + 1);
                (list[k], list[n]) = (list[n], list[k]);
            }
        }
    }
}

Usage:

var tasks = new List();
tasks.AddRange("Write code", "Test code", "Deploy code");

if (tasks.HasItems)
{
    Console.WriteLine($"Last task: {tasks.LastOrDefault}");
    tasks.Shuffle();
    Console.WriteLine("Tasks shuffled!");
}

Static Extensions - The Game Changer 🚀

Here's where things get really interesting. Extension blocks also support static extensions. These are extensions that apply to the type itself, not to instances of the type.

To define static extensions, you omit the parameter name in the extension block:

public static class ListExtensions
{
    // Static extension block - no parameter name!
    extension(List)
    {
        // Static property
        public static List Empty => new List();

        // Static method
        public static List CreateWithCapacity(int capacity)
        {
            return new List(capacity);
        }
    }
}

Now you can call these as if they were static members of the List<T> type:

// Using static extensions
var emptyList = List.Empty;
var capacityList = List.CreateWithCapacity(100);

Console.WriteLine($"Empty list count: {emptyList.Count}");
Console.WriteLine($"Capacity list capacity: {capacityList.Capacity}");

This is particularly powerful when you want to add factory methods or utility functions that are logically related to a type but don't operate on a specific instance.

A Practical Example: Building a Validator 🔍

Let me show you how extension blocks can make validation code much cleaner. Imagine you're building a simple user registration system:

public class User
{
    public string Username { get; set; } = string.Empty;
    public string Email { get; set; } = string.Empty;
    public int Age { get; set; }
}

public static class UserExtensions
{
    extension(User user)
    {
        // Validation properties
        public bool HasValidUsername =>
            !string.IsNullOrWhiteSpace(user.Username) &&
            user.Username.Length >= 3;

        public bool HasValidEmail =>
            !string.IsNullOrWhiteSpace(user.Email) &&
            user.Email.Contains("@");

        public bool IsAdult => user.Age >= 18;

        public bool IsValid =>
            user.HasValidUsername &&
            user.HasValidEmail &&
            user.IsAdult;

        // Validation method with detailed errors
        public List GetValidationErrors()
        {
            var errors = new List();

            if (!user.HasValidUsername)
                errors.Add("Username must be at least 3 characters");

            if (!user.HasValidEmail)
                errors.Add("Email must be valid");

            if (!user.IsAdult)
                errors.Add("User must be 18 or older");

            return errors;
        }
    }
}

Using these extensions becomes super clean:

var newUser = new User
{
    Username = "Bo",  // Too short!
    Email = "invalid-email",
    Age = 16
};

if (!newUser.IsValid)
{
    Console.WriteLine("User validation failed:");
    foreach (var error in newUser.GetValidationErrors())
    {
        Console.WriteLine($"- {error}");
    }
}

// Output:
// User validation failed:
// - Username must be at least 3 characters
// - Email must be valid
// - User must be 18 or older

Working With Generic Types 🎯

Extension blocks work beautifully with generic types, and the syntax stays clean and readable:

public static class DictionaryExtensions
{
    extension(Dictionary dict)
        where TKey : notnull
    {
        // Property to check if dictionary is empty
        public bool IsEmpty => dict.Count == 0;

        // Safe get method that returns default if key doesn't exist
        public TValue? GetOrDefault(TKey key)
        {
            return dict.TryGetValue(key, out var value) ? value : default;
        }

        // Method to merge another dictionary
        public void Merge(Dictionary other)
        {
            foreach (var kvp in other)
            {
                dict[kvp.Key] = kvp.Value;
            }
        }
    }
}

Usage:

var settings = new Dictionary
{
    ["MaxConnections"] = 100,
    ["Timeout"] = 30
};

var additionalSettings = new Dictionary
{
    ["RetryCount"] = 3
};

settings.Merge(additionalSettings);

// Safe access without throwing exceptions
int retries = settings.GetOrDefault("RetryCount");  // 3
int unknown = settings.GetOrDefault("Unknown");     // 0 (default)

if (!settings.IsEmpty)
{
    Console.WriteLine($"Settings loaded: {settings.Count} items");
}

Mixing Old and New Syntax 🔀

Here's the best part - you don't have to convert all your existing extension methods to use the new syntax! Both styles work perfectly together in the same static class:

public static class StringExtensions
{
    // Old style extension method
    public static string Reverse(this string str)
    {
        return new string(str.Reverse().ToArray());
    }

    // New style extension block
    extension(string str)
    {
        public bool IsEmpty => string.IsNullOrEmpty(str);

        public string Capitalize()
        {
            if (str.IsEmpty)
                return str;

            return char.ToUpper(str[0]) + str.Substring(1).ToLower();
        }
    }
}

Both styles are compiled to the same IL code, so there's no performance difference. You can migrate to the new syntax gradually, or keep using the old syntax if you prefer - it's totally up to you!

Important Things to Know ⚠️

While extension blocks are powerful, there are a few limitations you should be aware of:

1. No Extension Fields

You can't add fields to types through extensions. This means auto-implemented properties won't work:

extension(User user)
{
    // ❌ This won't work - it would need a backing field
    public string FullName { get; set; }

    // ✅ This works - no backing field needed
    public string FullName => $"{user.FirstName} {user.LastName}";
}

2. Generic Type Parameters Must Be Used

If you have generic type parameters, they all need to be used in the receiver type:

// ❌ This won't work - T2 is not used in the receiver
extension(List list)
{
    public void DoSomething() { }
}

// ✅ This works - all type parameters are in the receiver
extension(Dictionary dict)
{
    public bool IsEmpty => dict.Count == 0;
}

3. Can't Override Existing Members

Extension members can't override actual members of the type. If the type already has a method or property with the same name, the extension won't be accessible (the type's own member takes priority):

extension(string str)
{
    // This won't override string.Length!
    public int Length => str.Length * 2;
}

Real-World Scenario: Query Builder 🏗️

Let me show you a more complex real-world example - a query builder for filtering collections. This demonstrates how extension blocks can make your code more fluent and easier to read:

public class Product
{
    public int Id { get; set; }
    public string Name { get; set; } = string.Empty;
    public decimal Price { get; set; }
    public bool InStock { get; set; }
}

public static class ProductQueryExtensions
{
    extension(IEnumerable products)
    {
        public IEnumerable InStockOnly =>
            products.Where(p => p.InStock);

        public IEnumerable Expensive =>
            products.Where(p => p.Price > 100);

        public IEnumerable Cheap =>
            products.Where(p => p.Price < 50);

        public IEnumerable ByPriceRange(decimal min, decimal max)
        {
            return products.Where(p => p.Price >= min && p.Price <= max);
        }

        public IEnumerable SearchByName(string keyword)
        {
            return products.Where(p => 
                p.Name.Contains(keyword, StringComparison.OrdinalIgnoreCase));
        }
    }
}

Now look how beautiful the calling code becomes:

var products = new List
{
    new() { Id = 1, Name = "Laptop", Price = 1200, InStock = true },
    new() { Id = 2, Name = "Mouse", Price = 25, InStock = true },
    new() { Id = 3, Name = "Keyboard", Price = 75, InStock = false },
    new() { Id = 4, Name = "Monitor", Price = 300, InStock = true }
};

// Chain extensions naturally!
var affordableInStock = products
    .InStockOnly
    .ByPriceRange(20, 200);

foreach (var product in affordableInStock)
{
    Console.WriteLine($"{product.Name}: ${product.Price}");
}

// Output:
// Mouse: $25
// Monitor: $300

Why You Should Care About Extension Blocks 💡

Let me tell you why this feature is a big deal:

Cleaner syntax - Properties look like properties, not methods with empty parentheses
Better organization - Group related extensions in one place
Static extensions - Add factory methods and utilities to types naturally
Less repetition - Define the receiver once, use it for multiple members
Forward compatible - Works alongside existing extension methods

Extension blocks don't replace everything you can do with extension methods, but they make the common cases much more elegant and intuitive.

Conclusion ✅

Extension blocks in C# 14 are a significant evolution of the extension method concept. They give you the flexibility to extend types with properties, operators, and static members, all while maintaining the simplicity and clarity that makes C# such a joy to work with.

Whether you're building utility libraries, creating fluent APIs, or just trying to make your code more readable, extension blocks give you powerful new tools to work with. And the best part? You don't have to change any of your existing code - the new syntax works alongside the old, so you can adopt it at your own pace.

I encourage you to play around with extension blocks when .NET 10 drops, and see how they can improve your codebase. Start with small utilities, try converting some of your existing extension methods, and explore the possibilities of static extensions and extension properties.

I hope this post gave you a solid understanding of what extension blocks are and how to use them. Now equipped with this knowledge, you can write cleaner, more expressive C# code!

Thanks for reading! 👋🏻

The Essential Interfaces Every C# Developer Should Know

Rasheed K Mozaffar — Sun, 02 Nov 2025 22:38:37 +0000

Hello there! 👋🏻

If you use C# on a daily basis, or you code with it for some side projects, you will properly encounter a bunch of interfaces that seem to always be around, like IEnumerable<T>, ICollection<T>, and IDisposable. These are really common to see in almost every codebase, but there are some more hidden gems that you should also learn about, which is what we will be talking about in this post. We'll embark on a journey to understand some of C#'s most essential interfaces so that whenever one comes up, you know exactly why that interface would make sense and how it should be used.

IEnumerable & IEnumerator
IEquatable
IDisposable
IComparable
IEqualityComparer
Wrapping up

The sections of this post are NOT related. Assuming you have some knowledge of C#, feel free to skip and read whichever section you need; there's no linkage between the sections.

IEnumerable and IEnumerator

These two interfaces cause a lot of confusion for newcomers to .NET, and even experienced developers still don't understand the purpose of each of them, because we just use them as they are. But let's break them down.

IEnumerable is a contract that says a collection can be enumerated — in other words, you can use it in a foreach loop. It doesn’t perform the iteration itself; it just promises to hand you something that can.
IEnumerator is that something; it’s the object that actually walks through the collection, keeping track of where you are and exposing each element one by one.

It's quite niche to actually hand-roll an IEnumerable since C# ships with a huge variety of enumerable types that satisfy 99% of your use cases. However, we will still go over an implementation just in case this 1% did in fact hit, such that you are prepared.

using System.Collections;

public class FileLineEnumerable : IEnumerable<string>
{
    private readonly string _path;
    public FileLineEnumerable(string path) => _path = path;

    public IEnumerator<string> GetEnumerator()
    {
        using var reader = new StreamReader(_path);
        string? line;
        while (!string.IsNullOrEmpty(line = reader.ReadLine()))
            yield return line;
    }

    IEnumerator IEnumerable.GetEnumerator() => GetEnumerator();
}

This simple implementation of IEnumerable turns a file into a collection, making it possible to iterate through the lines of the file line by line and stream them back to the caller. Here's how this would be used:


var errorLogs = new FileLineEnumerable("logs.txt")
    .Where(line => line.Contains("ERROR"));

foreach (var log in errorLogs)
    Console.WriteLine(log);

By implementing IEnumerable, we were able to turn a normal .txt file into a collection that we can iterate through line by line!

NOTE 💡: What makes IEnumerable even more powerful is Deferred Execution. When dealing with instances of IEnumerable, you are not actually computing results, you're just building a pipeline that will stay there and ONLY execute when you actually need it to. In the previous code sample where we looked for ERROR logs in the text file, the Where LINQ function returns an IEnumerable<T>, so the filtering didn't actually happen until we enumerated the IEnumerable, which happens either when you use it in a foreach, or when you call things like ToArray(), ToList() and so on, keep that in mind!

IEquatable

Our next guy, the fellow interface who carries this slogan on its shoulders:

What does it mean for two objects to be equal?
~ IEquatable

In C#, every type implicitly or explicitly inherits from System.Object, which defines the following equality method:

public virtual bool Equals(object? obj);

This one is a bit slow and error-prone, because it's basically not type-safe, which makes the runtime have to do some work like null checks, validate type correctness (that you are not comparing Person to Address), and it would also have to unbox value types, so a lot of headache.

Enter IEquatable<T>;

public interface IEquatable<T>
{
    bool Equals(T? other);
}

This interface defines a type-safe method for equality checks on two objects of the same type.
Let's take a look at an implementation of this interface to understand it better, because this one is more practical than theoretical.
Say we have this User class:

public class User
{
    public string Username { get; set; } = string.Empty;
    public string Email { get; set; } = string.Empty;
}

Say in the system, users can have different usernames, but the same email, like think of the email as the unique ID, if I have these two user objects:

var user1 = new User()
{
    Username = "user-1",
    Email = "user1@mail.com"
};

var user2 = new User()
{
    Username = "user-2",
    Email = "user1@mail.com"
};

Each with a different username, but the same email, if I call Equals(object?) on them, it will hand me back false. That's because the default implementation of Equals(object?) inherited from System.Object, only checks if the two objects have the same memory reference, it only checks references equality, not properties or values, even if the two user object had the exact same values for both username and email, this would still return false.

Now let's implement IEquatable<T>:

public class User : IEquatable<User>
{
    public string Username { get; set; } = string.Empty;
    public string Email { get; set; } = string.Empty;

    public bool Equals(User? other)
    {
        if (other is null)
            return false;

        return string.Equals(Email, other.Email, StringComparison.OrdinalIgnoreCase);
    }

    public override bool Equals(object? obj)
        => Equals(obj as User);

    public override int GetHashCode()
        => StringComparer.OrdinalIgnoreCase.GetHashCode(Email);
}

This is the necessary implementation needed to change the equality comparison. However, you might see that we have overridden two other methods that are not part of the interface, which are Equals(object?) and GetHashCode(). Now implementing the interface alone would make the comparison by email alone work when you in fact call it on an instance of User like doing user.Equals(otherUser), but other constructs like List<T>, and HashSet<T> and those, they rely on the Equals(object?), so if you do list.Contains(user), thinking it would search for it by email, it would return false even if that email was indeed there. Also, if you try using the == operator, it would call the Equals(object?) under the hood, which would do reference equality checks only, as we mentioned before, so overriding these two functions is crucial when implementing the interface to avoid strange behaviors with equality checks, searching, and hash maps.

IDisposable

public interface IDisposable
{
    void Dispose();
}

IDisposable defines a single method Dispose(); this method's implementation becomes necessary when dealing with unmanaged resources. Before we dive in further, let's explain Managed and Unmanaged resources.

Managed Resources: Things that are fully controlled by the .NET runtime and garbage collector, these are normal objects, like when you do new User(), basically objects that live on the heap. The garbage collector, or GC, knows how to automatically reclaim the memory of them once they are no longer referenced.

Unmanaged Resources: Things that the GC does not understand, like it doesn't know how to reclaim their memory, things like file handles, database connections, and other wrappers like FileStream, SqlConnection, these wrappers hold on to unmanaged resources themselves, that's why it's needed to call Dispose() on them once you're done using them, or by putting them inside a using block, which internally calls Dispose on the resource once the block or scope ends.

Let's look at this implementation of a File Logger, which takes in a message and appends it to a log file:

public class FileLogger : IDisposable
{
    private readonly StreamWriter _writer;
    private bool _disposed;

    public FileLogger(string filePath)
    {
        _writer = new StreamWriter(filePath, append: true);
    }

    public void Log(string message)
    {
        if (_disposed)
            throw new ObjectDisposedException(nameof(FileLogger));

        var timestamp = DateTime.Now.ToString("yyyy-MM-dd HH:mm:ss");
        _writer.WriteLine($"[{timestamp}] {message}");
    }

    public void Dispose()
    {
        if (_disposed) return;

        _writer.Dispose();
        _disposed = true;
    }
}

Simple and easy, the StreamWriter holds on internally to unmanaged resorce that it needs to dispose of, so by implementing IDisposable on our file logger, we can call Dispose on the writer once the file logger is no longer needed and mark _disposed as true, this is necessary because Dispose must be ideompotent, meaning its safe to call it multiple times.

There are two ways to call Dispose, let's look at them both

// METHOD 1
using (var logger = new FileLogger("logs.txt"))
{
    logger.Log("Application started.");
    logger.Log("Processing request...");
}

// METHOD 2
var logger = new FileLogger("logs.txt");
logger.Log("Processing request...");
logger.Dispose();

The first will call Dispose automatically once the scope of the using ends, which is more convenient and reduces the chances of you forgetting to manually call it.

IComparable

Here's another interface that often gets confused with IEquatable, but they serve very different purposes. While IEquatable answers "are these two objects the same?", IComparable answers "which one comes first?"

public interface IComparable<T>
{
    int CompareTo(T? other);
}

The CompareTo method returns an integer that tells us the relative ordering:

Negative value: current instance comes before the other
Zero: they're equal in sort order
Positive value: current instance comes after the other

Let's say we're building a task management system where tasks have priorities and due dates. We want to sort tasks intelligently, first by priority, then by due date if priorities are the same.

public class Task : IComparable<Task>
{
    public string Title { get; set; } = string.Empty;
    public int Priority { get; set; }  // 1 = High, 2 = Medium, 3 = Low
    public DateTime DueDate { get; set; }

    public int CompareTo(Task? other)
    {
        if (other is null)
            return 1;  // null values go to th end

        // First, compare by priority (lower number = higher priority)
        int priorityComparison = Priority.CompareTo(other.Priority);
        if (priorityComparison != 0)
            return priorityComparison;

        // If priorities are equal, compare by due date
        return DueDate.CompareTo(other.DueDate);
    }
}

Now here's the beautiful part, once we implement IComparable<T>, our objects work seamlessly with sorting operations:

var tasks = new List<Task>
{
    new() { Title = "Deploy to production", Priority = 1, DueDate = DateTime.Now.AddDays(2) },
    new() { Title = "Code review", Priority = 2, DueDate = DateTime.Now.AddDays(1) },
    new() { Title = "Write tests", Priority = 1, DueDate = DateTime.Now.AddDays(1) },
    new() { Title = "Update documentation", Priority = 3, DueDate = DateTime.Now }
};

tasks.Sort();  // Automatically uses our CompareTo implementation!

foreach (var task in tasks)
    Console.WriteLine($"{task.Priority}: {task.Title} - Due: {task.DueDate:MM/dd}");

The tasks will be sorted first by priority (all Priority 1 tasks first), and within each priority level, they'll be sorted by due date. No need to write custom sorting logic everywhere, implement it once, and simply use it everywhere!

NOTE 💡: Similar to IEquatable<T>, there's also a non-generic IComparable interface that uses object as the parameter type. And just like with equality, the generic version is preferred for type safety and performance. Also, if you implement IComparable<T>, it's good practice to override Equals(object?) and GetHashCode() to maintain consistency; if two objects are "equal" according to CompareTo(object?) (returning 0), they should also be equal according to Equals(object?).

IEqualityComparer

Sometimes you need to compare objects in different ways depending on the context, or you're working with types you can't modify (like third-party library classes or built-in types). That's where IEqualityComparer<T> comes in; it's an external judge that decides if two objects are equal. Unlike IEquatable<T>, where we are comparing the instance against something else, this one is more on the outside and provides decent flexibility when changing comparison strategies.

public interface IEqualityComparer<T>
{
    bool Equals(T? x, T? y);
    int GetHashCode(T obj);
}

This interface lets you define equality logic that lives outside the objects being compared. Think of it as a referee that can look at two objects and decide if they're the same based on whatever rules you give it.
Let's say we're building an e-commerce system where we need to compare products in different ways, sometimes by SKU (Stock Keeping Units in case you dont know...), sometimes by name, and sometimes by a combination of attributes:

public class Product
{
    public string SKU { get; set; } = string.Empty;
    public string Name { get; set; } = string.Empty;
    public string Category { get; set; } = string.Empty;
    public decimal Price { get; set; }
}

// Comparer for checking if products are the same SKU
public class ProductSKUComparer : IEqualityComparer<Product>
{
    public bool Equals(Product? x, Product? y)
    {
        if (ReferenceEquals(x, y)) return true;
        if (x is null || y is null) return false;

        return string.Equals(x.SKU, y.SKU, StringComparison.OrdinalIgnoreCase);
    }

    public int GetHashCode(Product obj)
    {
        return StringComparer.OrdinalIgnoreCase.GetHashCode(obj.SKU);
    }
}

// Comparer for finding similar products (same name and category)
public class ProductSimilarityComparer : IEqualityComparer<Product>
{
    public bool Equals(Product? x, Product? y)
    {
        if (ReferenceEquals(x, y)) return true;
        if (x is null || y is null) return false;

        return string.Equals(x.Name, y.Name, StringComparison.OrdinalIgnoreCase) &&
               string.Equals(x.Category, y.Category, StringComparison.OrdinalIgnoreCase);
    }

    public int GetHashCode(Product obj)
    {
        return HashCode.Combine(
            StringComparer.OrdinalIgnoreCase.GetHashCode(obj.Name),
            StringComparer.OrdinalIgnoreCase.GetHashCode(obj.Category)
        );
    }
}

This implementation shows how this interface makes it easy to provide different, easily swapable comparison strategies based on whatever we want to achieve. These can also be passed to constructs like HashSet<T>, for example, to provide a way of comparing such that the set would only store instances that pass that comparison strategy to avoid duplication.
Let's look at how this is used with LINQ:

var inventory = new List<Product>
{
    new() { SKU = "LAPTOP-001", Name = "Gaming Laptop", Category = "Electronics", Price = 1299.99m },
    new() { SKU = "LAPTOP-002", Name = "Gaming Laptop", Category = "Electronics", Price = 1499.99m },
    new() { SKU = "MOUSE-001", Name = "Wireless Mouse", Category = "Accessories", Price = 29.99m },
    new() { SKU = "LAPTOP-001", Name = "Gaming Laptop Pro", Category = "Electronics", Price = 1299.99m }
};

// Find duplicate SKUs in inventory
var duplicateSKUs = inventory
    .GroupBy(p => p, new ProductSKUComparer())
    .Where(g => g.Count() > 1)
    .Select(g => g.Key.SKU);

Console.WriteLine("Duplicate SKUs found:");
foreach (var sku in duplicateSKUs)
    Console.WriteLine($"  - {sku}");

// Find all similar products (same name and category)
var similarProducts = inventory
    .Distinct(new ProductSimilarityComparer())
    .ToList();

Console.WriteLine($"\nUnique product types: {similarProducts.Count}");

// Using with HashSet for fast lookups
var processedProducts = new HashSet<Product>(new ProductSKUComparer());
foreach (var product in inventory)
{
    if (!processedProducts.Add(product))
        Console.WriteLine($"Already processed: {product.SKU}");
}

And that's it!

Wrapping up

I hope you found some value in this post. I intended to make it so that sections are fully independent, so if you're interested only in one, you can just read that part and get the knowledge you need. If you have questions or feel like this can be expanded to address more, please let me know in the comments section!

Thanks for reading! 👋🏻

From C# to Swift; Discovering new worlds!

Rasheed K Mozaffar — Sat, 28 Jun 2025 20:18:05 +0000

Hi There 👋🏻

I've been a C# guy for two years now, I started my writing journey on Dev with content focused on C# mainly, and everything I worked on in my career has always been C# or revolved around .NET and C# from my personal projects, to my blog posts, and my professional day-to-day job. But it came to me to try something crazy and that is to learn Swift!

But, Why?

Well, I wanted to build a macOS application not using a cross-platform framework or something like MAUI, Electron, React Native, or any of these. So, Swift it is!
I've been playing around with the language for a while and I'm lowkey liking it, like I'm not finding it extremely difficult to get used to it because it borrows a lot from the C family of languages, and it is statically typed with powerful type inference and a nice syntax.

So my question is, would you be interested in getting to see Swift content from my learnings and experience as a total newbie in this new world? Leave your thoughts in the comments! And don't forget to share any crazy combinations of languages you're trying, like me

C# - Swift 💪

That's my combo for now! What about yours?

Trying to Type Faster? Meet TypeWin

Rasheed K Mozaffar — Thu, 05 Jun 2025 11:12:54 +0000

Howdy folks 👋🏻

If you use a computer — whether it’s for programming, writing, or just everyday tasks — chances are you rely on your keyboard more than you think. From crafting blog posts and coding projects to drafting books or simply replying to emails, typing is a core part of your digital life.

Most people type at an average speed of 10 to 50 words per minute (WPM), which gets the job done, but it leaves a lot of room for improvement. The good news? With just a little focused daily training, you can dramatically boost your typing speed and accuracy, unlocking a faster, smoother workflow.

What is WPM?

Like any speed measurement unit, KPH or MPH for example, it's basically how many words you can type in a minute. According to a survey done in March 2025 by onlinetyping.org on 56,000 volunteers, 28,325 students participated in that survey, and according to the survey report, here are some interesting stats:

10,060(35.51%) students out of 28,325 have a typing speed between 30 to 40 WPM. 10,450 (36.89%) students have a typing speed below 30 WPM. Only 489(1.73%) students have a typing speed over 60 WPM.

Those were the results for the students who participated in that survey. Now, here are the stats for programmers, which I find interesting:

Approximately 73.42% of coders have a typing speed between 40 to 70 WPM. Only 3.4% of coders have a typing speed below 30 WPM. And 9.35% have sped over 70 Words Per Minute

Here's the link to the survey report if you're interested in reading it:

Online Typing .org 2025 March Average Typing Speed Survey Report

🚀 Introducing TypeWin — Make Typing a Thrill, Not a Chore

We’re incredibly excited to announce the release of TypeWin, now available on the Microsoft Store! 🎉
Check it out here on the website or get it from the Microsoft Store

TypeWin - The Windows Typists Club
TypeWin (Beta) - Microsoft Store

TypeWin isn’t just another typing app. It’s the result of deep user feedback, tons of testing, and a commitment to making typing practice something you actually want to do. Whether you're a complete beginner or a seasoned typist aiming to shave off milliseconds from your WPM, TypeWin is crafted to push your skills to the next level.

At its core, TypeWin is built around one belief: learning to type shouldn't be boring. That’s why we’ve reimagined the typing experience to feel more like a race than a lesson — one that’s packed with excitement, challenge, and growth.

And the fun doesn’t stop at solo practice. You'll find yourself climbing global leaderboards, smashing records, and representing your country in thrilling ranked matches. All of that, wrapped in a sleek and modern UI that’s both intuitive and beautiful.

Here's a list of the key features the app offers ⭐️

⌨️ Detailed Typing Stats
Track everything — accuracy, typos, WPM, word-specific performance, and more.

🏁 Race Mode
Take on personal bests or challenge top racers worldwide in competitive typing races.

🌍 Global Leaderboard
Represent your country and rise through the ranks by competing with other typists for the best time.

🧠 Word Precision Training
Struggling with certain words? Isolate and train on them until you nail them.

🧾 Language Variety
Practice typing in multiple languages to sharpen your skills across the board.

📶 Offline & Online Modes
Keep improving whether you’re on the grid or off it — no connection required.

☁️ Cloud Sync
Your stats and progress follow you across devices, effortlessly.

🖥️ Sleek Modern Interface
Clean, minimal, and distraction-free — just you and the keys.

🎯 Made for Progress
Whether your goal is speed, accuracy, or consistency, TypeWin gives you the insights and tools to reach it.

Currently, the application is only available on Windows. There are plans to begin building a web version for it so that more users can benefit from it. If you give it a try, feel free to drop your feedback in the comments section, things you liked, things you didn't, and how your experience was overall. We'd love to hear from you on this one!

Thanks for reading

10 Months as a Software Engineer

Rasheed K Mozaffar — Wed, 28 May 2025 06:49:21 +0000

Howdy folks 👋🏻

10 months ago, I got my first real job at an American startup working remotely, and that was a significant transition in my life, moving from working on simple learning projects by myself to working with a team of 4, with product management, agile methods and a bunch of new everyday tools, so here's my overview of my first 10 months as an entry level software engineer.

The beginning

After I graduated high school in 2022, I started learning web development on my own with C# and ASP.NET Core, and I was building some simple projects like a todo management app, a clinic management system, and a real-time chat app. Until June 2024, that's when I was hired as a Software Engineer 1, or basically, an entry-level Software Engineer.

For starter, I had to go through an onboarding project to familiarize myself with the tech stack and patterns we use, luckily I was already well experienced with Blazor and Web API so it was fairly easy for me to go through the project. The project was simple as an idea, but it required me to go through and learn some new things that I'd have to use on almost daily basis.

Clean architecture
MediatR and CQRS
Setting up a project in Azure DevOps
Creating a CI-CD pipeline for building and publishing the application to Azure App Services

And a few more things. I used to join daily scrum meetings and share my updates and progress with the team, showcasing some code snippets and progress on the user interface, while the team shared their progress on features we were integrating or bugs we were knocking out.

Since I already had good experience with a lot of things that the onboarding project is supposed to teach, I was done with it in 10 days, and soon enough I was participating and contributing on the actual codebase with my first contribution being a small bug that involved a tiny change of a line or two in a service project.

Things I learned

When I was working by myself, I thought I'd known everything and that I'm superiorly smart, but the moment I stepped foot into a real job, I felt I was lacking even basic knowledge, some imposter syndrome just kicking in. To me, it was hard to navigate a very large codebase with 30+ projects in a solution, while in my normal projects, the most complex project had 4-5 projects.

After a while, I started learning to read code better and understand where my focus should be when I pick up a new task, or the blast radius.

The blast radius of a code change, be it a new feature, a bug, or refactoring, is the scope of files that are going to be affected by that change. I learned this expression from listening to a podcast named .NET Rocks.

When I pick up a new task, first thing I got myself to do, is figure out what are the files I was going to touch, how does the flow go, like where is this code I'm changing/adding is going to be called from, and what is it going to call, this helped me navigate more quickly, and be able to move around more confidently because it was pin-pointing the area of work for me and I no longer had to bounce between files to know where my next step is.

Don’t seek guidance the moment you get stuck, at the very beginning, many things may not make sense, and understanding the problem at hand could be tricky if you’re not familiar with the codebase, but always give it a few tries before resorting to asking for guidance, because that will help you build a more robust foundation of the code you’re trying to understand since you’re breaking it down piece by piece yourself, and you’re also teaching yourself how to traverse a problem from start to finish. It’s very important to ask for guidance on things that might take you so long to figure out, because you will be using company time and resources if it’s going to take you days to resolve something that could be straightforward for one of your teammates, so it’s always important to balance between when to seek guidance on something, and when to try and wander on your own. But always make sure to give it at least a couple attempts before asking for help.

Another really cliche thing I’ve learned, programming isn’t always writing code, yes I know, all of us have heard that a bazillion times already, that’s because it’s true. Most often than not, you’ll find yourself chasing bugs, debugging old code to see why it’s no longer behaving as it should, or writing tests to verify the new code that was added, does indeed behave as it should. Additionally, you might get into design questions and architecture decisions, so it’s really not always freshly baked code and features you’ll be implementing.

One thing I also highly encourage other developers or generally anyone to do, is to be curious and get involved in things that may not even be your level. We have a pull request policy of at least two required reviewers, and these reviewers are senior-level engineers, even though I’m an optional reviewer, I still go ahead and review PRs, and sometimes I even leave comments for the PR owner to resolve. This not only trains you to get used to doing more senior-like tasks, but also makes you learn from the work of others, identify how your teammates are tackling problems, the solutions they’re using and how their perspective differs from yours on solving a particular problem. And most importantly, someone may forget or not notice some piece of code that’s not properly done, and it might slide to production which could cause bugs that are much harder to surface up later on, so you could also be doing your team a good favor as well if you pick up on.

Last but certainly not least, don’t be afraid to say “I don’t know.” That doesn’t mean you don’t try—it just means you’re honest. During my interview, I was asked a question about microservices and messaging libraries, which I wasn’t familiar with at the time. I felt stuck and couldn’t even begin to form a proper answer, so I simply said, “I don’t know.” To my surprise, I was actually praised for that. The interviewers took the time to explain it to me and said it was refreshing that I didn’t try to make something up. I was able to be honest because I had done well on previous questions. In moments where you genuinely don’t know something, it’s perfectly okay to admit it—sometimes, that honesty creates a great opportunity to learn.

Final thoughts

I wanted to share with this post some of things I’ve learned and experienced in my first 10 months as an entry level software engineer, I hope that might have taught you something or you found something that resonates with you. Feel free to drop your thoughts, the things you agree and disagree with in the comments section down below so others can benefit as well.

Thanks for reading

How do you choose a component library for your project?

Rasheed K Mozaffar — Mon, 11 Nov 2024 11:32:27 +0000

Hi there 👋🏻

Building user interfaces has never been easier, the abundance of beautifully crafted component libraries has made it incredibly effortless to build high-quality, rich and interactive user interfaces in a very speedy manner.

But with all the choices that are available out there, how do you choose? Is it the design, the development experience, the documentation? Or maybe a whole bunch of reasons and factors you take into consideration? 🤔

Drop your reasons in the comments section!

The Guardian Middleware: Handling Errors Globally in ASP.NET

Rasheed K Mozaffar — Sun, 20 Oct 2024 20:10:37 +0000

Hi There! 👋🏻

In a few past articles, I've talked about pure C# concepts, things like delegates, cancellation tokens, IQueryable and so on. In this article, we're focusing on something specific, which is Exception Handling, but on a global scale through the use of middleware components that we have in ASP projects. If that sounds interesting, buckle up and let's get the show going!

Exception Handling in General

The use of exceptions in our applications is a general mechanism, and it's used for a lot of different use cases and always handled in a variety of ways. In some codebases, you'll use exceptions to control the flow, as in this case:


public async Task<UserManagerResponse> RegisterUserAsync(RegisterRequest request)
{
    var existingUser = await _userManager.FindByEmailAsync(request.Email!);

    if (existingUser is not null)
        throw new UserCreationFailedException(message: "Email is taken");
    // code removed for brevity...
}

In the previous example, a custom exception is thrown to control the flow (a user already registered with the provided email), this approach is sometimes referred to as Exception based control flow. Others may use something else like the Result pattern to limit the use of exceptions across the codebase because throwing and handling exceptions is costly, as they have to propagate up the call stack and be handled somewhere else in the code, in addition to allocation of the Exception object. If you're interested in a more in depth analysis, check out this article:
Exception Performance Analysis - The C# Players Guide

Why Global Handling?

Assuming we have a Web API project, the code that throws exceptions needs to be handled somewhere, you could do that in the controller, for example the RegisterUser endpoint that uses the code shown previously:


try
{
    var registerResult = await _authRepository
                               .RegisterUserAsync(request);

    if (registerResult.Succeeded)
      ...
}
catch (UserCreationFailedException ex) // exception handled here and converted into an error response
{
    // sign up failed
    return BadRequest(new ApiErrorResponse
    {
        ErrorMessage = ex.Message
    });
}

If you're using exceptions to control the flow, which is a pretty common scenario in application development as it's an easy to implement approach, and has great developer experience as it makes the code straightforward to follow (in case it's done right), you are going to have to catch all those exceptions in some layer within your application to convert them into proper error responses that your users or API consumers can make sense of.

You can see where this is going, adding try {} catch {} blocks in your endpoints, services or whatever it is, is going to reduce the readability of your code, and it's going to add a lot of noise. Not to mention that it's tying more responsibilities to parts of the code that aren't intended to handle exceptions. Like your controller should receive a request, map it to the correct action, which calls the right service or performs the right query and send back the response. It shouldn't be accounting and handling all the exception types a service or repository might be throwing.

At a more abstracted level, if you're using something like MediatR and CQRS, your controller endpoints will mostly always contain the same lines of code, like this:


[HttpPost("login")]
public async Task<IActionResult> LoginUserAsync([FromBody] RegisterRequest request, CancellationToken cancellationToken)
{
    var command = new Login.Command(request);
    var response = await _sender.Send(command, cancellationToken);
    return Ok(new ApiResponse<LoginResponse>(response)
    {
        Message = "User login succeeded",
        IsSuccess = true
    });
}

Build the command/query, send it, return a response.

But in that case, who is handling the thrown exceptions? Enter the Global Error Handling Middleware, that's quite a mouthful

Global Error Handling Middleware

When you first start with ASP, you hear the terms Request pipeline and Middleware a lot, I've talked in a previous article about the request pipeline in ASP and what is a middleware, if you're interested you can check it out here:
The Request Pipeline in ASP NET Explained

In short, every request that comes into our application, will have to go through that pipeline, so we can take advantage of that, and put a single try {} catch {} block, which can handle all types of exceptions, and builds the appropriate response based on the type of the exception, so that our controllers, services and everything else, do not have to involve themselves in the process of handling the exceptions.

Creating a Middleware

Creating a middleware is actually pretty straightforward, there are two ways to create them, one by convention, and one by implementing the IMiddleware interface and implementing its InvokeAsync method, we'll use the first method which is by convention.

I do like to keep my middlewares in a folder named Middlewares, but that's up to you where to create the class.

Here's the code needed for our Middleware:


public class ErrorHandlingMiddleware
{
    private readonly RequestDelegate _next;

    public ErrorHandlingMiddleware(RequestDelegate next)
    {
        _next = next;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        try
        {
            await _next(_context);
        }
        catch (Exception ex)
        {
            await HandleExceptionAsync(context, ex);
        }
    }

    private async Task HandleExceptionAsync(HttpContext context, Exception exception)
    {

    }
}

I'll start off by explaining the flow, and then start implementing the HandleExceptionAsync method.

Since every request is going to come through this middleware, anywhere in the application, when an exception is thrown, this is where it's going to be caught and handled. This makes the logic of handling exceptions more centralized because now exceptions that are related to the user experience will be handled in this single place. Like this middleware will take the exceptions that interest the user, make a meaningful error response out of them, and send that back in the response.

Implementing the error handling logic

All exceptions inherit from the Exception base class, so the exception we're catching, can be casted to any custom exception, so in the HandleExceptionAsync method, we can do the following:


private async Task HandleExceptionAsync(HttpContext context, Exception exception)
{
    HttpStatusCode code = HttpStatusCode.InternalServerError;
    string errorMessage = string.Empty;

    // Handle the different exception types here
    switch(Exception)
    {
        case AuthenticationFailedException ex:
            code = HttpStatusCode.BadRequest;
            errorMessage = ex.Message;
            break;
        case NotAuthorizedException ex:
            code = HttpStatusCode.Unauthorized;
            errorMessage = ex.Message;
            break;
        case OperationFailedException ex:
            code = HttpStatusCode.BadRequest;
            errorMessage = ex.Message;
            break;
        case Exception ex:
            code = HttpStatusCode.InternalServerError;
            errorMessage = "Something went wrong. Please try again";
            break;
    }

    context.Response.ContentType = "application/json";
    context.Response.StatusCode = (int)code;
    var errorResponse = new ApiErrorResponse(code, errorMessage);
    var serializedErrorResponse = JsonSerializer.Serialize(errorResponse);

    await context.Response.WriteAsync(serializedErrorResponse);
}

The type named ApiErrorResponse is a simple class with two properties encapsulating the error message and the HTTP status code and it has the follow declaration:


public class ApiErrorResponse
{
    public string? ErrorMessage { get; set; }

    public int StatusCode { get; set; }

    public ApiErrorResponse(string errorMessage)
    {
        ErrorMessage = errorMessage;
    }

    public ApiErrorResponse(string errorMessage, int statusCode)
    {
        ErrorMessage = errorMessage;
        StatusCode = statusCode;
    }
}

The code in this method does one thing only, it looks at the type of the exception, and sets the response status code and content to the information extracted from the exception.

When you introduce a new type of exception, you can just add a case for it in the switch block, and the middleware will be able to handle that exception type as well, so all you have to do is create your new exception, start throwing it wherever you need, and just add a case for it in the middleware, and it'll be able to take care of transforming it to something you can send back to your users or API consumers.

Additional Benefit

Another benefit to this approach, because it's the central place concerned with handling exceptions, you can go on and inject a logger instance, and also centralize the logging of exceptions in the same middleware:


public class ErrorHandlingMiddleware
{
    private readonly RequestDelegate _next;
    private readonly ILogger<ErrorHandlingMiddleware> _logger;

    public ErrorHandlingMiddleware(RequestDelegate next, ILogger<ErrorHandlingMiddleware> logger)
    {
        _next = next;
        _logger = logger;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        try
        {
            await _next(_context);
        }
        catch (Exception ex)
        {
            await HandleExceptionAsync();
            _logger.LogError(ex);
        }
    } 
    ...
}

Finally, now that our middleware is in place, we need to go ahead and add it to the request pipeline. In Program.cs, add this line:


app.UseMiddleware<ErrorHandlingMiddleware>();

if (app.Environment.IsDevelopment())
{
    app.UseSwagger();
    app.UseSwaggerUI();
}

app.UseHttpsRedirection();

app.UseAuthentication();
app.UseAuthorization();

app.MapControllers();

app.Run();

💡 NOTE: Registering the error handling middleware first in the pipeline is crucial, because that will allow it to handle exceptions thrown in subsequent middleware components in the chain, and so it'll be able to deal with ultimately any exception our application is going to throw in case that exception occurred during the processing of an incoming request.

Conclusion

Phew! We made it to the end! We've looked, discussed and implemented global error handling mechanism! Take a bow!
The post was quite long but we've looked at quite a few things, from understanding the purpose of exception handling globally, creating the middleware, and seeing how to actually handle the exceptions. Now for any scenario where you want to deal with exceptions on a global, more centralized level, you can use this approach, and tailor it to match your exact needs!

Forem: Rasheed K Mozaffar

My Best Advice as a Software Engineer

Hello There 👋🏻

Introduction

Don't just ask "What should I do?"

Moral of the story

Thanks for reading

Pattern Matching in C#: The Starters Guide

Hey there! 👋🏻

What is Pattern Matching? 🤔

The Classic Switch Statement (The Old Way) 🕰️

Switch Expressions (The New Way) ✨

Type Patterns 🎯

Property Patterns 🔍

Relational Patterns 📊

Logical Patterns (and, or, not) 🧮

Real-World Example 🌍

When to Use Pattern Matching ⚙️

Conclusion ✅

Thanks for reading! 👋🏻

Having Issues Installing Visual Studio Extensions on ARM Devices? Do this

Howdy! 👋

Step 1

Step 2

Step 3

Step 4

Step 5

Conclusion ✅

Thanks for reading 👋

How do you use AI in your work? And what's your limit?

Hello there! 👋

Exploring the new .slnx Visual Studio Solutions Format

Hey there! 👋🏻

What's the .slnx Format? 🤔

Why Should You Care? 💡

How Do You Use It? 🛠️

Should You Switch? ⚖️

Conclusion ✅

Thanks for reading! 👋🏻

Exploring Extension Blocks in .NET 10

Hey there! 👋🏻

Prerequisites 🛠️

A Quick Refresher on Extension Methods 🔄

The Problem With Traditional Extension Methods 🤔

Introducing Extension Blocks 🎉

Converting a Traditional Extension Method

Real-World Example: String Extensions 📝

Multiple Extensions in One Block 🗂️

Static Extensions - The Game Changer 🚀

A Practical Example: Building a Validator 🔍

Working With Generic Types 🎯

Mixing Old and New Syntax 🔀

Important Things to Know ⚠️

1. No Extension Fields

2. Generic Type Parameters Must Be Used

3. Can't Override Existing Members

Real-World Scenario: Query Builder 🏗️

Why You Should Care About Extension Blocks 💡

Conclusion ✅

Thanks for reading! 👋🏻

The Essential Interfaces Every C# Developer Should Know

Hello there! 👋🏻

Table of Contents

IEnumerable and IEnumerator

IEquatable

IDisposable

IComparable

IEqualityComparer

Wrapping up

Thanks for reading! 👋🏻

From C# to Swift; Discovering new worlds!

Hi There 👋🏻

But, Why?

C# - Swift 💪

Trying to Type Faster? Meet TypeWin

Howdy folks 👋🏻

What is WPM?

🚀 Introducing TypeWin — Make Typing a Thrill, Not a Chore

Thanks for reading

10 Months as a Software Engineer