Getting Time For What’s Important – Dev Leader Weekly 17

Hey there!

Thanks so much for folks that took the time on last week’s poll. The newsletter will continue to along the current format. This means that I’ll try to include an exclusive article, early access to a video, content recaps as well as some other general tips at the end. I’ll periodically ask for your feedback to ensure that it remains helpful to you.

And because you’re all awesome… this week’s exclusive article has early access to TWO YouTube videos released next week. I felt bad for not getting blog articles done so I stayed up late to provide you with videos ahead of time.

A quick reminder that you can refer your friends to sign up for my newsletter! You can get free membership access for a few months to my site to access the newsletter archive and my Behind The Screen weekly vlogs that I do. Check out the details at the end of this issue.

Prioritization – Getting Time For What’s Important

Only So Much Time

In this week’s exclusive article, I’m going to share with you something groundbreaking: We all have the same amount of limited time to get work done.

Hopefully your sarcasm detector is working and you’re still reading. But the reality is with limited time and often seemingly unlimited things to focus on, how can we get some traction back? Are there ways we can minimize randomization in our work days? Can we do better with prioritizing?

I’ll share my perspective as a Principal Engineering Manager at Microsoft along with my thoughts as a software engineer. Just because I don’t write code at work anymore doesn’t mean I forget these things!

Priorities Between Work Streams

Often as software engineers, we’re dealing with more than one thing at a time. Whether that’s wrapping up the last bug fix or feature while you’re learning about the next new area or trying to fix a late-breaking issue while you have another ongoing feature to deliver… It’s a normal thing we deal with. Ideally, we’re working in a streamlined way where this doesn’t affect us, but I just don’t think it’s realistic to not plan for and accept in some capacity.

Engineering Manager’s Philosophy

My personal philosophy when it comes to workstream priorities is that I want my team members to have as much autonomy as possible. I want to ensure they can shift fluidly between different work as they need without necessarily relying on me to make decisions like that for them. But it’s only possible if I do my job to help establish clear focus areas and priorities with my team.

If the team isn’t cohesive in their understanding of focus areas and what’s currently most important for delivering value — there’s no way I can expect them to make good decisions about priority. This is a key point which brings us to the next section…

Do You Know The Milestones?

If you’re juggling different workstreams, stop and ask yourself if you know the milestones for each. If it’s clear, then you’ll have an easier time aligning the dates with the amount of effort involved and the priority of the work.

For example, if your #1 priority item for impact is actually due in 2 months, but the #2 priority item is due in two days… from an impact perspective, if you don’t focus on getting #2 done quickly you might miss ALL of the potential impact it could have. But if you didn’t know the deadlines for milestones/deliverables for either and just kept moving along… you might put the effort in the wrong spot.

You *DO* Know The Priority, Right? …Right?!

I can see the look on your face. This seems like a dumb thing to point out… If someone knows the priority then they don’t have an issue prioritizing it. Duh!

But consider typical randomization that can happen to software teams — and this looks different at different places. For software engineers I work with, they might have other teams contacting them directly for help on deliverables. And they are *REALLY* good at selling just how urgent something is to the other software engineers.

But… Do they know the priorities of that work stacked against our current work? Probably not. They potentially (likely) have no idea what we’re doing. And I don’t expect my team members to always know this — so please ask when new stuff crops up and you’re not sure on priority. It’s best to get alignment early!

Check out this early-access video for my discussion on these topics:

3.5 Ways To Improve Organizing Your Time

Now that we have prioritization out of the way, let’s talk about your calendar. As software engineers, we want to ensure we have an opportunity to get into a state of flow as much as possible. Uninteruppted work can be a magical thing. Here are my 3.5 tips for helping improve this:

1. Theme Days or Portions of Days – This allows you to try and group your calendar (as much as possible) into days or time blocks where you’ll do meetings vs types of work you can try and get full focus on. Some meetings you don’t own the schedule for, but that’s okay. Try to get yourself several hours of contiguous time in your calendar you can use for focus. And then…
2. Block Your Calendar – Yes. Be selfish. Block it off. It doesn’t mean that you can’t ever take a meeting in this time, but you are setting boundaries and prioritizing your focus. If someone NEEDS you in a meeting and you don’t give up your time block, they’ll reschedule. If they truly don’t need you, then you just drove some positive efficiency. But how do you know based on the goals of the meeting?
3. Clarify Meeting Goals – Goals are not motions of what will be done in the meeting (i.e. we will talk about project A B C). Goals are the desired outcomes of the meeting. Understand these before going, because if it’s truly not important or valuable for you to be there then
   • 3.5. Say No – There’s nothing wrong with it. If you aren’t going to get or provide value, you should feel free to say no. (disclaimer: if your org has strict policies around this, maybe sort that out first). I personally need to do better at this.

Check out this video before it releases next week for a rundown of these tips:

Thought-Provoking Quote of the Week:

Communication is underrated by so many software engineers – especially early on in their journey. Engineering in general is an extremely technical area, and folks that focus on writing code as a primary means of doing their work are… well… very technical! There’s so much drive and focus on improving technical skills, but often communication is left in the dust.

The reality is: you’ll be limited by your ability to communicate effectively at some point in your software engineering journey if you don’t prioritize improving it. And I don’t mean something like you need to speak X language fluently – I mean that you need to be able to effectively communicate thoughts, ideas, perspectives, etc… And you need to do this with a wide variety of roles and backgrounds.

At a minimum, if you’re writing code – this means that you have other software engineers that need to read it. So consider that your ability to convey ideas via your written language is paramount even just to code.

Don’t forget to prioritize this area 🙂

Featured Content:

This week was incredibly busy for me, as I mention in my vlog. Between the activities I mention as well as a big project I am aiming to deliver mid December – I haven’t been able to keep up with article writing. 6 full-length articles per week is… a ton. But I got my videos out still!

The Ultimate Beginner’s Guide to Flags Enums in CSharp

One of the more slightly advanced features with Enums in C# is that we can make them “flags”. If you’ve never used this before with Enums, give this video a watch and see how you can apply flag Enums in your code!

You’re Using Enums in C# Wrong – So Do This!

This video dives into one of the most common issues that I personally see with how people use Enums. Disclaimer: I am not anti-Enum, but I am anti-make-more-work-for-yourself-later!

CSharp Switch Statements – How To Control Your Code

This is an intro guide to using switch statements in C#. If you’re just getting started with switch statements or you’ve never used them before, this is a great place to start!

Discovering The Features Of DotNetFiddle – How To Compile C# Online

This week’s single article that I was able to put together is on DotNetFiddle. It’s one of my favorite free C# tools, and you’ll notice that I use it in my live streams as well as for sharing solutions for the weekly coding challenges. It’s a great combination of simple and useful. And no – I don’t have any affiliation with it (especially important to note that… it’s free!).

Solution to Last Week’s Coding Challenge:

Did you try out last week’s coding challenge? Well – there’s no quick code snippets this time for an answer! Last week was building an application to try and practice ASP.NET core development. Getting behind what I preach – the quicker algorithmic questions can be something fun to solve but I think there’s more value in you trying to build some small applications!

This Week’s Coding Challenge:

This week’s challenge is focused on understanding hash tables, one of the fundamental data structures in computer science. Your task is to implement a custom HashMap (or dictionary) in C# from scratch!

Problem Statement:

Design a HashMap without using any built-in hash table libraries. The HashMap should provide the following functionalities:

1. void Put(int key, int value): Insert a (key, value) pair into the HashMap. If the key already exists, update its corresponding value.
2. int Get(int key): Returns the value to which the specified key is mapped, or -1 if this map contains no mapping for the key.
3. void Remove(int key): Removes the mapping for the value key if this map contains the mapping for the key.

Constraints:

• All keys and values will be in the range of [0, 1000000].
• The number of operations will be in the range of [1, 10000].
• Do not use any built-in hash table libraries.

Method Signatures:

public class MyHashMap 
{
    public MyHashMap() 
    {
        // Constructor
    }

    public void Put(int key, int value) 
    {
        // Your code here
    }

    public int Get(int key) 
    {
        // Your code here
        return -1;
    }

    public void Remove(int key) 
    {
        // Your code here
    }
}

Tips:

• Consider using an array or list to implement the underlying structure of the HashMap.
• Handle potential collisions with a strategy such as chaining (using linked lists or another structure at each array index) or linear probing.
• Aim for efficient operations. The average time complexity for each method should be O(1) under typical conditions.

This challenge is excellent for grasping the internal workings of one of the most used data structures, understanding key concepts like hashing and collision resolution, and improving problem-solving skills. Happy coding!

As always, thanks so much for your support! I hope you enjoyed this issue, and I’ll see you next week.

​Nick “Dev Leader” Cosentino
​[email protected]​
​
Socials:
– Blog​
– Dev Leader YouTube​
– Follow on LinkedIn​
– Dev Leader Instagram​
​

P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers. Let’s grow our community together!

Nick Cosentino Principal Software Engineering Manager

Principal Software Engineering Manager at Microsoft. Views are my own.

See Full Bio

ASP.NET C# DotNet .NET Software Engineering