For the past two years, I've created feature roadmaps at the beginning of the year as a way to gradually improve parts of this blog. I do this for a couple of reasons.

1. It's a way to avoid the trap of tinkering with the blog instead of writing posts
2. It keeps the technology and features of this blog up to date and continually improving

I make the roadmaps public in this site's GitHub [README](https://github.com/aaronmbos/personal-site#feature-roadmap). As I've mentioned previously, the plan for this quarter (Q3 2023) was to improve the blog post search experience on the site.

I wanted to make improvements to the experience because there were a few features that I intentionally left out of the initial release and that I felt were needed to make the entire experience a little more user-friendly. Here's the list of improvements that I set out to complete.

- Search blog posts by tag(s)
- Show a loading state on the search result page while searching
- Use the forward-slash `/` to place focus on the nav search input

While a bit of work went into each of these small features, I am only going to dive a bit into the first feature for searching posts by tag. The other two are pretty self-explanatory and are really just UX improvements overall.

### Search blog posts by tag(s)

Previously the search functionality worked in a way that the most relevant posts would be returned based on the search term and any matching field in the search index.

When indexing posts for search, the following fields are stored.

- Title
- Description
- Slug
- Tags
- Content
- Publish Date

Recently new functionality was added to the search that allows a user to search posts by a tag or tags. To do this you simply need to start your search with `tag:<tag_to_search>`.

![search-single-tag](https://res.cloudinary.com/aaron-bos/image/upload/v1694741237/search-single-tag_jdwriy.png)

In addition to searching for a single tag users can also search for multiple tags by appending more tags after the `tag:` prefix delimited by commas. This will return all posts that contain any of the tags in the list (think an OR operation for inclusion).

```shell
tag:tag1,tag2,tag3,tag4
```

![search-multiple-tag](https://res.cloudinary.com/aaron-bos/image/upload/v1694740654/search-multiple-tags_kh6pkn.png)

This new search functionality is great and allows users to be a bit more specific in their searches. Unfortunately, the feature is not that discoverable on its own. For that reason, I also made a slight change to the UX for the "tag identifiers" listed on each post. Previously those tag identifiers were simply there to indicate the tags for the post. Now they've been updated to buttons that when clicked will perform a search for the tag that you clicked on. Let's take a look at this feature from the home page.

![tag-click-search](https://res.cloudinary.com/aaron-bos/image/upload/v1694741085/tag-click-search_ldejfu.gif)

In a previous [post](https://aaronbos.dev/posts/announce-search-feature), I mentioned that Algolia is the service used behind the scenes to provide search on my blog. Searching by attributes did require a slight modification to the search index configuration. 

Algolia has the concept of "facets" that allow users to refine search results with multiple categories. For example, facets would allow a user to refine a search for a specific title or tag. This is a bit different from the default filtering functionality. So for this feature, I simply needed to update the index configuration to allow for tags to be included in facet searches.

I hope you enjoyed this quick look at a new feature of the blog this quarter. Next quarter we'll be looking at cleaning up the `/posts` route by reducing the static page size and introducing pagination. 


At the beginning of the year, I created a roadmap to plan the development of my blog itself. In this post, I'll talk through the improvements for this quarter that involved the blog post search experience. Let's dive in!

Q3 Roadmap Feature: Search Improvements

## First ask, "Is it necessary?"

Whenever the words "parallel", "concurrent", "thread-safe", or the like come up in system design conversations I'll ask myself if any of those things are actually necessary. The answer may depend on several factors.

- Is the system in question wholly new or existing?
- What are the known constraints on the system (network, CPU, memory, etc.)?
- Has this been done before or is it uncharted territory?
- If performance is in question, do we have any measurements or benchmarks?

There are other factors that play into system design decisions, but I will typically opt for simple solutions initially and hold off introducing complexity until it becomes apparent that the simple solution won't continue to work.

I think there's an inherent complexity that comes with writing code that needs to be executed consistently in parallel or from multiple threads. Numerous aspects of programming become more complicated when code is executed at the same time. For example, understanding the general flow of a program and debugging both become more challenging.

With all of that being said, throughout my career, I've taken the approach of attempting to learn the underpinnings of technology in order to help me utilize it effectively. This post is my attempt to share my understanding of the underlying complexity in "thread safety", which contributes to my comfort in using it as needed.

## Thread safety in general

According to [Wikipedia](https://en.wikipedia.org/wiki/Thread_safety) the definition of thread safety is:

> A computer programming concept applicable to multi-threaded code. Thread-safe code only manipulates shared data structures in a manner that ensures that all threads behave properly and fulfill their design specifications without unintended interaction.

The interesting aspects of this definition lie in the complexity of "behaving properly" and "fulfilling their design specifications without unintended interaction." The reason for this is that they can mean different things to different programs in different situations. Behaving properly for my application that requires concurrent reads may be completely different than behaving properly for your application requiring concurrent writes. 

Most software will provide some level of guarantees against common multi-threaded problems such as deadlocks and race conditions, but those levels and guarantees will differ based on the software you're utilizing.

This is where the importance of going another layer deeper comes into play. Once we've decided that parallelism is needed, do we have the ability to understand how our program needs to behave and can we achieve that behavior with a given toolset? For the purpose of this post, our toolset will be the libraries .NET provides for threading.

## Managed Threading in .NET

The main goal of threading is to increase application responsiveness or overall throughput. In .NET a program is started on a single thread, but it is possible to create additional threads for the program to execute in parallel or concurrently. When operating in a single-threaded manner, the program can really only accomplish one task at a time. When multithreading is introduced, the program is able to do multiple tasks simultaneously which leads to more responsiveness and throughput (generally speaking). In .NET an object is considered to be thread-safe if it can be called from multiple threads without the potential for interrupting calls that are taking place across threads. In the next section, we'll look more closely at the techniques and primitives available for managing this.

When possible multithreaded operations should use the [Task Parallel Library](https://learn.microsoft.com/en-us/dotnet/standard/parallel-programming/task-parallel-library-tpl) or [PLINQ](https://learn.microsoft.com/en-us/dotnet/standard/parallel-programming/introduction-to-plinq) because they provide great abstractions over raw threads. These libraries rely heavily on [System.Threading.ThreadPool](https://learn.microsoft.com/en-us/dotnet/api/system.threading.threadpool?view=net-7.0) for multithreaded behavior and by default all thread pool threads will be background threads.

Multithreading can be pretty straightforward in certain scenarios, but often times there will be challenges with managing shared state or data. For example, a collection or property may need to be accessed or updated from multiple threads. How can we go about doing that without running into issues of accessing value at the same time or the data being out of sync? This is where thread safety comes in. Luckily for us .NET provides a great deal of functionality to help us avoid "shooting ourselves in the foot" when dealing with multithreading.

Typically thread safety will involve some synchronization mechanism, which manages the complexity of making sure that multiple threads are not trying to access or modify the data at the same time. There are different synchronization mechanisms (some of which I'll mention in the next section), but their main purpose is to avoid common issues like deadlocks and race conditions. Let's take a look at some of these synchronization techniques that are used by .NET under the hood to avoid common multithreading problems in our code.

## Synchronization Techniques

In this section, I'll be covering some of the manual techniques that can be used to provide thread safety in .NET. I'd like to mention that in most cases it is best to use the higher level libraries like TPL and PLINQ instead of implementing synchronization by hand. This section is intended to shed a little light on what might be going on behind the scenes in the higher-level abstractions.

The first synchronization technique that we'll be discussing involves the `lock` keyword which is used to control access to shared resources. When using locks in our code there are a few general guidelines to follow.

- Don't share the same lock for multiple shared resources
- Don't lock `this` because it could be used by callers
- Don't lock types because they may be requested through reflection
- Don't lock string instances because they could be accessed through string interning

In the code sample below we've created a private field called `_scoreLock` to act as a lock controlling access to the `_score` field. The lock ensures that only a single thread can access and modify the integer value at a time.

```csharp
using System;
using System.Collections.Generic;
using System.Linq;
using System.Threading.Tasks;

public class Program
{
  private static object _scoreLock = new object();
  private static int _score = 0;
  
  public static void Main()
  {
    Parallel.For(0, 20, (idx) => AddScore(idx * 2));
  }

  private static void AddScore(int value)
  {
    lock(_scoreLock) 
    {
      Console.WriteLine($"Increasing the score by {value}");
      _score += value;
    }
  }
}
```

While using the `lock` keyword may seem low-level, we can actually look another layer deeper at the Monitor class which is used by `lock`.

The Monitor class is used for controlling access to a block of code by acquiring and releasing a lock object. If that sounds similar to the `lock` keyword, it should be under the hood the `lock` keyword uses a couple of static methods on the Monitor class to synchronize access to the block of code. Let's take a look at the `AddScore` method from our previous example after it has been compiled to see what the lowered C# code looks like.

```csharp
private static void AddScore(int value)
{
    object scoreLock = _scoreLock;
    bool lockTaken = false;
    try
    {
        Monitor.Enter(scoreLock, ref lockTaken);
        Console.WriteLine($"Increasing the score by {value}");
        _score += value;
    }
    finally
    {
        if (lockTaken)
        {
            Monitor.Exit(scoreLock);
        }
    }
}
```

As you can see the `lock` keyword is no longer present in the code sample after it has been compiled. The `lock` block is replaced with a `try/finally` block. In order to acquire the lock, `Monitor.Enter` is called passing in the lock object and a boolean to indicate whether the lock has been taken. The finally block ensures that the lock object is released after use with `Monitor.Exit`.

In my opinion, one of the trickier aspects of understanding thread-safety in .NET is that there are several ways to achieve **similar** synchronization behavior, but each method has slightly different functionality that can make a huge difference when choosing the right one. I'm not going to go into each one of these methods in depth, but I'll provide a bit of information that is relevant to using the method of synchronization.

- **[Mutex](https://learn.microsoft.com/en-us/dotnet/api/system.threading.mutex?view=net-7.0)**
  - The `Mutex` class is similar to `Monitor` except that mutexes can be used to synchronize data between processes.
- **[SpinLock](https://learn.microsoft.com/en-us/dotnet/api/system.threading.spinlock?view=net-7.0)**
  - The `SpinLock` class will wait for access to a lock by repeatedly looping until it the lock is available.
- **[ReaderWriterLockSlim](https://learn.microsoft.com/en-us/dotnet/api/system.threading.readerwriterlockslim?view=net-7.0)**
  - `ReaderWriterLockSlim` limits access to a lock for writing, but allows multiple threads access for reading.
- **[Semaphore](https://learn.microsoft.com/en-us/dotnet/api/system.threading.semaphore?view=net-7.0)** and **[SemaphoreSlim](https://learn.microsoft.com/en-us/dotnet/api/system.threading.semaphoreslim?view=net-7.0)**
  - Semaphores in .NET differ from the `Monitor` class in that they don't have thread affinity, which means locks can be acquired and released from different threads
  - If you're interested in learning more about semaphores, I wrote a post about them previously [here](https://aaronbos.dev/posts/how-to-use-semaphoreslim-csharp).

## Summary

Thread-safety and multi-threading are difficult and I think this post is an example of their difficulty. I could have gone on much longer and dug much deeper, but I'll leave that for you if you're interested. I hope this post was helpful in gaining a better understanding of thread safety in general and provides an on-ramp to learning more in the future.

## Resources

[https://learn.microsoft.com/en-us/archive/blogs/ericlippert/what-is-this-thing-you-call-thread-safe](https://learn.microsoft.com/en-us/archive/blogs/ericlippert/what-is-this-thing-you-call-thread-safe)

[https://en.wikipedia.org/wiki/Thread_safety](https://en.wikipedia.org/wiki/Thread_safety)

[https://learn.microsoft.com/en-us/dotnet/standard/threading/threads-and-threading](https://learn.microsoft.com/en-us/dotnet/standard/threading/threads-and-threading)

[https://learn.microsoft.com/en-us/dotnet/standard/threading/overview-of-synchronization-primitives](https://learn.microsoft.com/en-us/dotnet/standard/threading/overview-of-synchronization-primitives)

Writing code that always behaves as expected when run in parallel is HARD. I'll be the first to admit that I'm NOT an expert in this field, but I do my best to generally understand the principles that make parallel programming possible. This post attempts to unpack the "thread-safe" term for writing .NET code and explain some of the techniques that allow for thread safety to be possible.

Understanding Thread-Safety in .NET

I'd like to preface this post by saying that these experiences are based on what I've learned personally after a few weeks of being an Engineering Manager. They may not apply directly to everyone, but I find it helpful to take a step back and think about take aways from the transition so far.

## What I've Learned So Far

**It's not a promotion.** While going from Senior IC to Engineering Manager may seem like a promotion on the surface, in most cases **it's not**, and I'm completely fine with that. I've had multiple people congratulate me on the "promotion" and LinkedIn even considered the position change a "promotion" automatically but in the grand scheme of things I've technically made a lateral move to a different career track. I'll touch more on responsibilities later but for me, the biggest change in being a manager is the required mindset shift.

**Thinking like a manager** is slightly different from the thinking required for being an IC. As a manager, I need to have a broader range of focus to make sure that my team is working on the right things at the right time for the business. I also have a stronger focus on how effectively my team is performing as a whole to achieve our goals. This differs from system/project/design based focus that I maintained as a Senior IC. I still need to be focused on the technical aspects of projects, but the direction and priority of what the team is working on are equally (if not more) important for me to understand.

**I still get to write code!** One of my biggest fears when thinking about transitioning to Engineering Manager was losing my ability to write code and solve problems. Your mileage may vary with team size and needs, but my team is quite small and I've still been able to contribute to tickets in the sprint while maintaining my management duties. My goal is to do what I can to make space for the talented engineers on my team to do what they do best. If that means taking on a bit of work that's off the critical path that keeps my team focused on our goals, then I'm happy to do it. I'm still learning the right balance, but so far the change in the amount of coding hasn't been massive for me.

**I still have a lot to learn** about being an effective manager, but the challenges that it has presented so far have been fun and interesting. I'm looking forward to continuing to grow in this role as a leader on my team and excited for all of the great things we'll be doing. I plan to periodically write posts about what I'm learning and my experiences transitioning from an IC to a manager.




I recently made the switch from Senior Engineering to Engineering Manager 😱. In this post, I'll share some general thoughts on the experience so far. While everyone's experience and situation is different, I think it's helpful to share my initial thoughts about making the transition a successful one for everyone.

Engineer to Manager: Initial Thoughts

**First, I would definitely recommend this [book](https://a.co/d/1IYnXbh)** to those who struggle with mindset, don't believe mindsets can change, or those who are looking to understand the impact that a mindset shift can have on their life. The book is packed with examples and stories that support Carol Dweck's extensive research on mindset, which helps drive home the point while also making it an exciting read.

**Growth vs Fixed Mindset** A person with a ***growth mindset*** will be more willing to embrace challenges, learn from criticism, and generally value effort over outcomes. Whereas someone with a ***fixed mindset*** will avoid challenges for fear of failure, neglect criticism, and value outcomes over effort. These mindsets can be surfaced in any aspect of our life including careers, relationships, and interests. 

**Our mindset can be multi-faceted.** Prior to reading this book, I assumed that everyone mostly took on a singular mindset. _"I am either a growth-minded or fixed-minded person."_ Through this book I learned that individuals can have a growth mindset in some areas, but a fixed mindset in others. For example, I may have a growth mindset in how I approach my career, but a fixed mindset in how I approach personal relationships. Understanding this is important because it can help identify areas we should improve. It may also be worth trying to learn why some areas are easier to have a growth mindset than others to shed light on ways to improve.

**Mindsets are linked to identity.** Most people will find an identity that acts as a guide for the decisions they make throughout their lives. For example, many people will identify themselves based on their talents or successes. For the longest time, I identified myself as an athlete. Sports dominated my life from my youth through college, but what happened when I had to stop playing? There was a period of time when I felt like I had lost my identity, but in time I came to realize that it wasn't necessarily the athletic successes that I identified with. It was the **effort and pursuit to be great at something**. Once I realized that I was able to shift my mindset from being an "athlete" to being a "learner". Someone who is constantly looking to improve and grow. Because I didn't find my identity in the outcomes, I was able to make the transition without completely redefining my purpose and identity.

Life can be challenging. We are put into situations that challenge us mentally and physically all of the time. The mindset that we have going into these situations can significantly affect the outcome positively or negatively. In this post, I'll share my takeaways from the book Mindset by Carol Dweck which focuses on using a growth mindset to navigate difficult situations.

Developing A Growth Mindset

## What are Extension Methods

Before getting too deep, let's all get on the same page in regard to extension methods. I could try to summarize the [documentation](https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/extension-methods) for you, but I think it's summed up pretty well in the first paragraph.

> Extension methods enable you to "add" methods to existing types without creating a new derived type, recompiling, or otherwise modifying the original type. Extension methods are static methods, but they're called as if they were instance methods on the extended type. For client code written in C#, F#, and Visual Basic, there's no apparent difference between calling an extension method and the methods defined in a type.

## History of Extension Methods

I mentioned in the intro that extension methods have been around for a "long time". In fact, extension methods have been around since .NET 3, which was released in November 2007. The motivating factor behind the introduction of extension methods was LINQ. In order to make the LINQ API more natural, the methods were defined as extensions to the frequently used collection interfaces. This feature's quality of life improvement probably deserves more credit than it has been given. Can you imagine having to use a static method on `IEnumerable<T>` to call `Select` 🤮?

```csharp
// Not great
IEnumerable.Select(someCollection, x => x == y);

// Chef's kiss
someCollection.Select(x => x == y);
```

Extension methods are all over .NET class libraries. So much so that we often use them without even realizing it. While many developers are frequent consumers of extension methods, not everyone writes them. 

## Creating Extension Methods

Extension methods are straightforward to create, but there are criteria that need to be met in order to be valid.

1. The class that contains the extension method must be public and static.
2. The extension method must be public and static (static is a given since it is a member of a static class).
3. The first parameter of the extension method needs to be of the type that is being extended and needs to include the `this` modifier.
4. Extension methods can't be the same name as an existing method on the type that is being extended.

Here is an example of an extension method.

```csharp
public static class AaronExtensions
{
    public static bool AreYouAaron(this string str) 
    {
        return str?.Equals("Aaron", StringComparison.OrdinalIgnoreCase) ?? false;
    }
}
```

In code, we can then reference the `AreYouAaron` method on a string as if it were actually a method defined in the String class.

```csharp
public class AaronFinder {
    static void Main() {
        var aaron = "Aaron";
        
        Console.WriteLine(aaron.AreYouAaron());
        Console.WriteLine("nigel".AreYouAaron());
    }
}
```

Extension methods are pretty neat and provide some interesting options for engineers when it comes to developing clean APIs. With that being said they are a little quirky with special requirements and syntax. Let's take a look at what happens "under the hood" once extension methods have been compiled.

## Extension Methods Post-Compilation

Since extension methods "pseudo extend" an existing type, it's safe to assume that the C# compiler is performing some magic behind the scenes to make it all work. If we look at the decompiled extension method from earlier we'll notice a few things.

1. The static class and method are defined with the `[Extension]` attribute
  - This tells the compiler that the class contains extension methods and that the member is an extension method respectively
2. The `this` modifier is no longer included in the compiled code
3. When the extension methods are actually called, they are called like normal static methods using `AaronExtensions.AreYouAaron`

```csharp
[Extension] // 1. 
public static class AaronExtensions
{
    [System.Runtime.CompilerServices.NullableContext(1)]
    [Extension] // 1.
    public static bool AreYouAaron(string str) // 2. 
    {
        return str != null && str.Equals("Aaron", StringComparison.OrdinalIgnoreCase);
    }
}

public class AaronFinder
{
    private static void Main()
    {
        string str = "Aaron";
        // 3.
        Console.WriteLine(AaronExtensions.AreYouAaron(str));
        Console.WriteLine(AaronExtensions.AreYouAaron("Nigel"));
    }
}
```

## Resources

- [https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/extension-methods](https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/extension-methods)

- [https://sharplab.io/](https://sharplab.io/)

Extension methods have been around in .NET for a long time and most developers use them daily without even realizing it. In this post, we're going to take a closer look at extension methods and how they work. Let's dive in!

Hey! 👋

My name is Aaron Bos and this is my blog.

Recent Posts