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!

A Closer Look at C# Extension Methods

## What is "Dark Matter Time"?

In order to get to the dark matter portion of this metaphor we need to start with matter. 

> Matter is any substance that has mass and takes up space by having volume. - [Wikipedia](https://en.wikipedia.org/wiki/Matter)

In software development, I compare matter to the time we spend working on a given development task. This time includes work like writing code, testing the code, deploying, company/team meetings, and project planning. This work is all top of mind when thinking about the time it takes to complete a task.

In a perfect world, we would be able to track and confidently estimate the amount of time a given task takes because the work required is similar to the work required to complete previous tasks. In reality, estimating work is hard and never exact. Why is that? 

Estimation is difficult for a multitude of reasons that are unique to individuals and teams, but I think one of the ubiquitous reasons for this is that there is time in our daily work that is difficult to account for. This is where **dark matter** comes in.

> Dark matter is a hypothetical form of matter thought to account for approximately 85% of the matter in the universe. Dark matter is called "dark" because it does not appear to interact with the electromagnetic field, which means it does not absorb, reflect, or emit electromagnetic radiation and is, therefore, **difficult to detect**. - [Wikipedia](https://en.wikipedia.org/wiki/Dark_matter)

So how does dark matter relate to the time in a software engineer's day? I like to think of dark matter time as the time spent on work that is required, but not apparent. This includes things like context shifting, waiting for answers to questions, researching alternate solutions, and communicating with teammates and stakeholders.

In the same way, that dark matter is difficult to detect and quantify in the real world, so too is "dark matter time" in the software development world. Dark matter time is always present in our work, but not consistent across tasks or even across engineers. In my experience learning to detect and manage this time effectively is a key piece to growing as an engineer.

## Managing Dark Matter Time

We know "dark matter time" exists and we know that it is hard to predict, so what practices, habits, or tools do we have at our disposal to manage it?

**Step 1: Detect dark matter time.** I've mentioned previously that dark matter time is hard to predict, but we can normally detect it when it is just about upon us. In my experience being able to detect these periods of time when the work "feels like it's done" can reduce ambiguity because I feel prepared for it.

**Step 2: Develop a plan.** This step may sound a little formal, but in reality, a plan doesn't need to be a written list or tracked. A plan can be as simple as forming some thoughts around what to do next given the task at hand. Some examples of this might be shoring up a PR by doing some self-review or spending a little extra time learning about a language/framework/technology feature that is relevant to the work you've done or are doing. 

In some cases, this may be looking for the next task to work on, but I often try to avoid making that my default choice because moving on before a previous task is done can often lead to overly painful context switching.

**Step 3: Execute.** This final step is simple. Once we've decided how we are going to manage this time that we may not have planned for, we can confidently go about executing.

At the end of the day, some of this comes down to time management, but I think even the most prudent of timekeepers can fall prey to the unpredictability of dark matter time. For this reason, I find it helpful to be prepared and make use of that time to the extent that I can.  

As I've grown in my software engineering career I've learned that time isn't always easy to manage. Learning to deal with writing code, context shifting, collaborating, and all of the other aspects that go into being an effective engineer can be challenging. In this post, I'm going to try to flesh out the idea of "dark matter time" and how we can learn to use it effectively. Let's dive in!

Managing "Dark Matter Time"

## The Changelog

[The Changelog](https://changelog.com/podcast) is hosted by [Adam Stacoviak](https://changelog.com/person/adamstac) and [Jerod Santo](https://changelog.com/person/jerodsanto). They release three weekly episodes on Monday, Wednesday, and Friday. Monday's episode is a short (5-10 minute) software and technology news show with a companion [newsletter](https://changelog.com/news/40/email). Wednesday's show is a deep-dive interview with a guest from the software and technology world. Finally, Friday's episode is a "Changelog and Friends" show where a guest joins Adam and Jerod to chat informally about various (still mostly tech-related) topics.

I've been a long-time subscriber to The Changelog because I enjoy their interview style. Adam and Jerod have a way of interviewing guests that makes the episodes interesting and entertaining. Along with the flagship show, The Changelog has an entire family of podcasts that cover topics ranging from front-end development to AI. We'll be talking about one of them next with JS Party.

## JS Party

As you can probably guess from the name [JS Party](https://changelog.com/jsparty) is a show focused on JavaScript (and TypeScript 😏). While JS is in the name, I consider JS Party to be a podcast that covers topics from the front-end software development world. So there may be episodes about frameworks, libraries, tools, and technologies relating to front-end development. JS Party features a rotating panel of hosts and they normally have at least one guest in each episode.

Even though I'm not a front-end engineer by trade, I find it very beneficial to stay up to date on the latest news and trends in the space. Since I maintain this blog and other small apps, I find it useful to have a high-level understanding of what is popular in the front-end development world. I've been subscribed to JS Party for a long time and look forward to a new episode in my Podcasts app each week!

## Soft Skills Engineering

[Soft Skills Engineering](https://softskills.audio/) is a recent addition to my podcast lineup that has quickly become one of my favorites. The show is [hosted](https://softskills.audio/meet-the-hosts/) by Dave Smith and Jamison Dance. Each week they provide advice in the way of answers to listener questions. The type of advice that Dave and Jamison provide contains a great mix of reality and humor. I find that they're able to speak honestly about situations that might normally be difficult to discuss in a professional setting.

They cover things like:

- Getting promoted
- How to deal with being laid off
- Resolving workplace conflict
- Asking for a raise

These are all topics that we, as knowledge workers in technology, will have to deal with at some point in our careers. I find the Soft Skills Engineering podcast to be a great way to learn how others think about or handle these normally difficult scenarios.

## CoRecursive

[CoRecursive](https://corecursive.com/) is currently my favorite podcast. The show is released about once a month and each episode is an interesting story about a specific person or project in technology. The tagline from the site is:

> The stories behind the code

I find each episode of CoRecursive captivating my attention from start to finish. As consumers, we only see the end result of products, but the host, Adam Gordon Bell, does an amazing job shedding light on all of the struggles that took place to reach the end state. My favorite episode to date is the [episode](https://corecursive.com/serenity-os-with-andreas-kling/) detailing the story behind SerenityOS and its creator Andreas Kling. I highly recommend giving it a listen.

## Software Unscripted

[Software Unscripted](https://open.spotify.com/show/0cWHExP9zgcPaaSRScHVtO) might be the most technically deep podcast that I listen to. The host, Richard Feldman, is currently building a functional programming language called [Roc](https://www.roc-lang.org/). For this reason, many of the guests contain deep knowledge of programming language design and architecture. I'll admit that I don't necessarily understand everything discussed in the episodes, but I do come away from each episode with something new or interesting to explore.

There's my list! In the past few months, I reduced the number of shows that I'm subscribing to while also listening at 1.25X speed. I used to listen at 2X speed but found myself breezing through episodes without really getting much from them. I've definitely shifted from pure quantity to filtering my list for quality. If any of these shows seem interesting, I highly recommend giving them a listen. Podcasts are not my primary mode of learning, but they are definitely a mode that I use to learn passively. 

For the past several years podcasts have been an integral part of my personal development process. Each year I like to share the podcasts that I'm subscribed to with the goal of spreading the word and explaining why I find them worth listening to. Here's my list for 2023!

Hey! 👋

My name is Aaron Bos and this is my blog.

Recent Posts