Have you ever sat down at your computer, ready to get into a flow state, and then spent the first ten minutes just arranging windows? Dragging your editor here, your browser there, nudging Slack into a corner - only to close it all two hours later, and start from scratch the next day? Yeah. Me too.

I've been a big fan of Microsoft PowerToys for a while now. It's one of those tools that quietly makes your Windows experience feel a lot more intentional. There are a bunch of great utilities in there - but recently I've been leaning heavily on one in particular: PowerToys Workspaces.

What is PowerToys Workspaces?

Workspaces is a Windows desktop management utility that lets you capture your ideal window layout, which apps are open, where they're positioned, what size they are, and then launch that entire setup with a single click.

Think of it like a saved game state, but for your desktop.

You could have a "Coding" workspace that opens VS Code to a specific project, a browser on the side, and Terminal ready to go. Or an "Email & Admin" workspace that brings up Outlook, your calendar, and a notes app. Whatever your workflow looks like - you set it up once, and Workspaces handles the rest every time.

Setting Up Your First Workspace

If you haven't already got PowerToys installed, you can grab it from the Microsoft Store or via WinGet. Once it's running, head into the PowerToys Settings and enable Workspaces.

To create your first workspace:

1. Hit Win + Ctrl + ' to open the Workspaces editor (or go to Settings and click "Launch editor").
2. Click "+ Create workspace".
3. You'll enter Capture mode - arrange your apps exactly how you want them.
4. When you're happy hit "Capture".
5. Give it a name, tweak anything you need to, and save it.

That's it. When it you launch it, it will open those apps exactly as you'd like them. You can create as many different workspaces as you'd like depending on your needs.

The Part That Surprised Me

What I didn't expect was how useful the CLI arguments feature would be. When you're in the editor, each app has a little dropdown where you can pass command line arguments. So for VS Code, I can point it straight to a specific project folder on launch. For Edge, I can give it a comma-separated list of URLs and it'll open all those tabs automatically.

It sounds like a small thing - but removing those few extra clicks every time you start a session adds up surprisingly quickly.

Desktop Shortcut

Within the workspace editor, you can select the option to Create a desktop shortcut which creates a handy shortcut on your desktop.

I find this super handy for when I start my PC first thing in the morning. Just a double click and your workspace is loaded and ready to go. If you prefer, you could pin it to your taskbar if you really want it front and centre.

A Few Things Worth Knowing

When a workspace launches, you'll briefly see windows jumping around the screen as PowerToys repositions them. There's a status dialog that pops up to show you what's loading, which helps - but it can look a bit chaotic the first time you see it.

Also worth noting: if you've got apps snapped using Windows' built-in snap feature, Workspaces won't preserve that snapped state. It uses its own positioning engine under the hood. Not a dealbreaker, but something to be aware of when you're setting things up.

How I Use It Day to Day

If you've read my recent post on staying technical as a TPM, you'll know I'm always looking for ways to reduce friction and stay in a coding mindset. Workspaces has become one of those small but surprisingly impactful habits.

I've ended up with two workspaces that cover probably 90% of my week:

• Coding - VS Code, Terminal, and a browser window with the relevant docs.
• Daily - Outlook, Teams, Slack and a browser.

Switching between them takes a double click. It sounds almost too simple - but honestly, that's the point. The friction of setting up your environment is just gone.

If you haven't explored PowerToys yet, it's one of the best free productivity tools for Windows and the Workspaces docs are a great place to start.

In my career, I've been many things - a Support Engineer, a Software Engineer and an Engineering Manager. These days, I've settled into a Technical Program Manager role (which I am thoroughly enjoying).

As a Technical Program Manager (or TPM), you're often expected to wear multiple hats - strategic planner, cross-functional communicator, and technical problem solver. But how do you stay technically sharp while managing programs at scale?

The role of a TPM is different from a program manager, you are expected to be technical. Here are some of the daily (and weekly) practices that help me keep my technical skills sharp.

Writing the occasional code

Early in my career, I was a software engineer. These days, my role doesn’t require me to write code, but I still have the urge to explore and tinker. I’ve built a bunch of small tools and love updating my GitHub account. I’m also big into AI right now (as is everyone 😂) and have been doing a lot of “vibe coding” just to learn something new or scratch an itch. Even writing a few lines here and there keeps your brain tuned to real engineering challenges.

Writing Technical Content

Blogging has been a powerful tool for learning. Whether it’s writing about Azure Text-to-Speech, troubleshooting Ghost CMS, or Game Development, the act of explaining technical concepts forces clarity and deepens my understanding. It also helps others, which is always a bonus.

Following tech blogs

One of the most useful habits I’ve developed is staying up to date with what’s happening across the tech world. Even if it’s not tech I use every day, it’s important to see how others are solving problems. You never know when a piece of tech or a pattern will end up being useful later.

<Insert your hobby here>

Outside of work, I love brewing my own beer. I even have a blog dedicated to it! One of the best ways to learn something new is to combine your hobby with tech. Recently, I built a fermentation tracker using a Raspberry Pi and temperature sensors. It keeps me close to hardware and scripting, and it’s a fun, low-stakes way to apply engineering principles.

Balancing technical depth with program management isn’t about doing everything - it’s about staying curious, being useful, and knowing when to dive in. Whether it’s through side projects, internal tools, or collaborative problem‑solving, staying hands‑on helps me lead with more confidence and empathy. It might all sound obvious, but the real impact has come from deliberately doing these things, day after day, with intention.

How to Stay Close to Your Company's Tech

While it’s important to understand what’s happening across the wider tech landscape, it’s just as important (if not more so) to stay close to the technology inside your own organisation. Knowing how your systems work, how your teams build, and where the real challenges live helps you make better decisions and builds trust with engineering.

Here are some of the things I try to do in my role to stay close to the tech:

Read Your Company’s Engineering Docs
Most teams have design docs, architecture overviews, or RFCs floating around. Even skimming them gives you a deeper understanding of how things fit together and why certain decisions were made.

Sit In on Architecture or Design Reviews
You don’t necessarily need to weigh in on every detail, but observing the discussions helps you understand trade‑offs, constraints, and how engineers think about the system.

Spin Up a Local Dev Environment
Even if you’re not coding every day, setting up and running the services your teams build helps you understand the tooling, dependencies, and workflows they use.

Use the Product Like a Real User
If your company makes consumer or developer-facing tools, actually use them end-to-end. It sharpens your instincts for what “good” feels like and what’s actually painful.

Why Staying Technical Matters for TPMs

• Credibility with Engineering Teams: Understanding the tech stack helps you ask the right questions and gain trust. This is especially important in a gaming role! If engineers don't believe you are credible and have the background knowledge, it becomes much harder to lead effectively.
• Better Decision-Making: Technical fluency helps you assess trade-offs, spot risks, and understand what “good” looks like.
• Faster Problem Resolution: When you understand the underlying systems, you can catch bottlenecks or misalignments earlier.

Time Management

So how do I fit all this learning time in?

In a busy work environment, it can be tricky to stay current while balancing program responsibilities. I also have a family, and being a present dad is non-negotiable.

One thing that has helped tremendously is deliberately blocking time for learning or tinkering - without compromising program delivery. For example, I use Feedly to read all the RSS feeds I subscribe to. First thing in the morning with a cup of coffee, I catch up on what's happening in our industry.

At Microsoft, we also have company-wide hackathons, and they’re a fantastic opportunity to try something new, collaborate with people you’ve never worked with, and solve real technical challenges. I try to participate whenever I can.

Balancing learning and work isn’t easy, but scheduling time for both makes it achievable.

Conclusion

I hope you’ve found this post useful. These are the things that have personally helped me stay technically sharp - they might not all be right for you, but it’s a good place to start. For me, it ultimately comes down to staying curious, being deliberate, and consistently carving out time to keep learning.

If you're a Technical Program Manager, how do you stay technical? I’d love to hear your approach.

Have you ever wanted to create a backup of your website or blog? Maybe you're migrating to a new platform, or perhaps you just want a portable archive of your content that you can read offline. I've previously experienced issues with this site going down and I wanted to make sure that I wasn't stuck without a backup of all my posts.

That's exactly why I built Backup Buddy - a command-line tool that turns any website into a collection of clean, readable Markdown files with all the images (and videos) preserved.

What Does Backup Buddy Do?

Backup Buddy takes a website's sitemap and automatically downloads every page, converting the HTML into clean Markdown format while saving all the images (and videos) locally. Think of it as creating a time capsule of your website that you can read, search, and store anywhere - no internet required.

The best part? You end up with content in Markdown format, which means you can:

• Read it in any text editor
• Import it into a static site generator like Hugo or Jekyll
• Search through it with standard text tools
• Version control it with Git
• Share it without worrying about broken links or missing images

How to Use It

Using Backup Buddy is straightforward. You just need to know your website's sitemap URL (usually something like https://yoursite.com/sitemap.xml) and run a single command:

backup-buddy https://yoursite.com/sitemap.xml

That's it! The tool will:

1. Download your sitemap
2. Find all the URLs
3. Download each page
4. Convert the HTML to Markdown
5. Save all the images
6. Organize everything into neat folders

Getting Started

Head over to the Git repo and download the latest release.

What You Get

After running Backup Buddy, you'll find an output folder with all your content organized like this:

output/
├── 1_my-first-post/
│   ├── my-first-post.md
│   ├── metadata.txt
│   ├── images/
│   │   ├── header-image.jpg
│   │   └── diagram.png
│   └── videos/
│       └── demo.mp4
├── 2_another-post/
│   ├── another-post.md
│   ├── metadata.txt
│   └── images/
│       └── photo.jpg
└── ...

Each page gets its own folder containing:

• The Markdown version of your content
• A metadata file with the original URL and backup date
• An images folder with all pictures from that page
• A videos folder with any videos from that page

Why I Built This

I've been blogging for years, and I've migrated platforms more than once. Each time, I worried about losing content, breaking image links, or dealing with complicated export tools. I wanted something simple that would give me a clean backup I could actually use.

The Markdown format is perfect because it's:

• Human-readable - You can open it in any text editor
• Future-proof - It's just text, so it'll work forever
• Portable - Easy to import into almost any blogging platform or static site generator
• Git-friendly - You can track changes and collaborate on content

Performance Features

One thing I made sure to include was speed. Backup Buddy processes multiple pages at once (10 by default), so even large websites with hundreds of pages get backed up quickly. You'll see real-time progress as it works:

[1/150] Processing: https://example.com/first-post
[2/150] Processing: https://example.com/second-post
  ✓ Saved to: output/1_first-post
  ✓ Saved to: output/2_second-post
[3/150] Processing: https://example.com/third-post
...

A Few Things to Know

While Backup Buddy handles most websites well, there are a few limitations:

• It only backs up URLs in your sitemap (which is usually everything important)
• Content that's loaded with JavaScript after the page loads won't be captured
• Images need to be accessible when you run the backup
• Very large sites might need you to adjust the parallel processing settings

Try It Out

If you've been looking for a simple way to backup your website or blog, give Backup Buddy a try. It's open source (MIT License), so you can use it freely and even modify it for your needs.

Check it out on GitHub: github.com/deanhume/backup-buddy

Have questions or suggestions? Feel free to open an issue or submit a pull request. Happy archiving!

If you’ve ever had an app crash at the worst possible moment, you’ll know how frustrating it can be - both for developers and players. Recently, I wrote an article for the Microsoft Developer blog that dives deep into this exact challenge: how to diagnose and resolve crashes effectively on Xbox and Windows platforms.

In the post, I share practical tips, tools, and workflows that can help you move quickly and efficiently. Whether you’re building games or apps, these techniques can improve the overall experience for your users.

👉 https://developer.microsoft.com/en-us/games/articles/2025/11/from-crash-to-resolution-practical-guide-for-xbox-windows-developers/

If you’ve got any thoughts or tips of your own, I’d love to hear them — drop a comment or reach out!

Back in 2013, I published a blog post about a simple HTML Minifier I'd built for web pages. At the time, web performance was becoming increasingly important, and I needed a straightforward way to reduce the size of HTML files in my projects. What started as a personal solution has evolved into a tool that's been used by developers worldwide for over a decade. Today, I want to reflect on that journey and share what the tool has become.

The Problem (Then and Now)

Web performance has always been critical, but it's even more important today. Every KB matters when you're trying to deliver fast experiences to users across the globe on varying network conditions. While we have sophisticated build tools and bundlers now, the core principle remains the same: smaller files load faster.

HTML minification removes unnecessary whitespace, line breaks, and comments from your HTML files - things that make code readable for humans but add unnecessary bytes for browsers. When you're shipping production code, these extras are just wasted bandwidth.

What Started as a Simple Tool

The original HTML Minifier was straightforward: point it at a folder of HTML or ASP.NET Razor views, and it would strip out the unnecessary characters. It was born from a real need I had while working on ASP.NET projects where manually minifying views or integrating complex build processes wasn't practical.

HtmlMinifier.exe "C:\MyProject\Views"

That was it. Simple, effective, and it got the job done.

Evolution Over 12 Years

What's been fascinating is watching the tool evolve based on real-world usage and community feedback. Here are some of the key improvements that have shaped the project:

Framework Support

Early on, I learned that aggressive minification could break certain JavaScript frameworks. Knockout.js, for example, uses HTML comments for control flow. Angular had similar patterns. This led to adding configuration flags:

# Preserve HTML comments for frameworks that need them
HtmlMinifier.exe "C:\Folder" ignorehtmlcomments

# Keep Knockout.js comments specifically
HtmlMinifier.exe "C:\Folder" ignoreknockoutcomments

This was a great lesson in understanding your users' workflows. A tool is only useful if it fits into real-world scenarios.

Performance Improvements

As the tool gained users, performance became more important. People weren't just minifying a handful of files - they were processing entire web applications with thousands of views. I added:

• Recursive directory scanning for processing entire project structures
• Multi-file support for targeted minification
• Line length controls to prevent overly long lines that could impact certain text editors or source control systems
• Performance metrics showing bytes saved and processing time

# Limit lines to 60,000 characters
HtmlMinifier.exe "C:\Folder" "60000"

Modern Development Practices

The .NET ecosystem has changed dramatically since 2013. The project has evolved alongside it:

• Continuous Integration: GitHub Actions now automatically build and test every commit
• Comprehensive Testing: Over 60 unit tests covering edge cases, performance benchmarks, and real-world scenarios
• Better Error Handling: Proper validation, informative error messages, and graceful failure modes
• Cross-framework Support: HTML, Razor views (.cshtml), and Web Forms (.aspx)

Community Contributions

One of the most rewarding parts of this journey has been the incredible support from the community. Over the years, twelve different contributors have jumped in to help improve the tool - surfacing bugs and edge cases I hadn’t considered, submitting fixes for real-world production issues, adding support for specific frameworks and use cases, and even enhancing the documentation and usage examples.

Every pull request, issue, and suggestion has helped shape the tool into something better.

Performance Gains

The tool typically achieves:

• 10-40% size reduction for typical HTML files
• 20-50% reduction for files with heavy indentation and whitespace
• Processing speeds that can handle thousands of files in seconds

For a production website with hundreds of views, this translates to meaningful bandwidth savings and faster page loads.

Lessons from Maintaining an Open Source Tool

1. Simplicity is a Feature

In an era of complex build toolchains, there's still value in tools that do one thing well. The HTML Minifier has survived because it's simple to understand and use. You don't need to configure Webpack, install npm packages, or learn a new build system - you just run it.

But I'm also mindful that sometimes the best feature is knowing what not to add. The tool's simplicity is part of its appeal.

2. Real Users Reveal Real Problems

Some of the most impactful improvements came directly from folks using the tool in production. They uncovered edge cases I hadn’t even considered - like deeply nested HTML structures, Unicode and international character handling, quirky Razor syntax combinations, and performance bottlenecks with massive files. Their feedback helped push the tool to be more robust and production-ready.

3. Open Source is a Marathon

Twelve years is a long time. Technologies come and go, but useful tools persist. The key is:

• Responding to issues thoughtfully
• Being conservative with breaking changes
• Keeping the tool focused on its core purpose
• Appreciating and crediting contributors

Try It Yourself

If you're working on a web project and need a straightforward way to minify HTML, give it a try:

GitHub: https://github.com/deanhume/html-minifier

Reflections

Looking back at 12 years of maintaining this tool has been surprisingly rewarding. It's been used in projects I'll never know about, solved problems I didn't anticipate, and connected me with developers around the world.

The web development landscape has changed dramatically since 2013:

• We've gone from jQuery to React, Vue, and beyond
• Build tools have become incredibly sophisticated
• Web performance tooling has advanced tremendously
• The rise of SPAs, PWAs, and modern frameworks

Yet through all these changes, the need for efficient HTML delivery remains constant. That's perhaps the most interesting lesson: fundamental problems persist even as technologies evolve.

Thank You

To everyone who's used the tool, filed an issue, contributed code, or simply found it helpful - thank you. Open source thrives on community, and this project has been a small but meaningful part of my contribution to that ecosystem.

Here's to another 12 years of making the web a little bit faster, one minified file at a time. 🚀

Resources:

• GitHub Repository
• Original Blog Post (2013)
• Latest Release

If you've recently ventured into the world of Azure Functions, you're likely familiar with the versatility they offer when it comes to scheduling tasks. In this guide, we'll delve into using Azure Functions' Time Trigger function with Node.js and Visual Studio Code, uncovering some important nuances along the way.

This article assumes that you have some familiarity with Node.js and a basic understanding of Azure.

Getting Started

To begin, you'll need Node.js and Visual Studio Code installed, along with the Azure Functions extension. When you create a new function, it comes with some boilerplate code that includes a schedule property defining when the function should run. By default, it's set to run every 5 minutes.

const { app } = require('@azure/functions');

app.timer('timerTrigger2', {
    schedule: '0 */5 * * * *',
    handler: (myTimer, context) => {
        context.log('Timer function processed request.');
    }
});

The schedule parameter in the above code tells the Azure Function how often to fire.

The Challenge

But what if you want your function to run every 11 hours during a day? Crafting the right Cron expression can be tricky, and that's where I encountered some difficulties. I turned to an online Cron expression generator, hoping it would simplify the process. Here's what it gave me:

0 0 */11 * *

Feeling confident, I integrated this expression into my code above and deployed the Azure Function. However, it didn't work as expected. I scoured the logs for clues but found nothing. To troubleshoot and debug locally, I temporarily changed the Cron expression to run every minute, and it worked flawlessly. So why wasn't it firing every few hours?

The Revelation

After some online research, I uncovered the reason behind the issue. Azure Functions use an NCRONTAB expression, which requires a six-part format instead of the traditional five-part Cron expression. The online generator that I found online had provided a five-part expression, leading to the problem.

To be fair, the Visual Studio Code extension for Azure Functions provides the correct six-part format by default. My mistake was changing it using a five-part expression from an online tool - d'oh!

The Solution

To rectify this, I recommend using the NCrontab Expression Tester. This user-friendly tool not only helps you test your expressions but also generates the correct six-part Cron expressions tailored for Azure Functions.

When I updated my code to use the 6 part format:

0 0 */11 * * *

It ran perfectly!

Why NCrontab?

You might be wondering why Azure Functions use the NCrontab six-part format instead of the traditional five-part format. The answer lies in its flexibility. The six-part format allows you to specify seconds, enabling you to run your functions with higher precision and frequency.

* * * * * *
- - - - - -
| | | | | |
| | | | | +--- day of week (0 - 6) (Sunday=0)
| | | | +----- month (1 - 12)
| | | +------- day of month (1 - 31)
| | +--------- hour (0 - 23)
| +----------- min (0 - 59)
+------------- sec (0 - 59)

For further details on NCrontab expressions, you can visit the GitHub repository here.

Happy coding!

In my spare time, I like to do a bit of homebrewing. While it isn't the usual sort of topic that I post on this site, I wanted to cross post to an article I wrote about automating some of the brewing process.

If you've ever goofed around with Raspberry Pi's before, you'll know how fun they can be. In this article I go into detail about how I hooked up a Raspberry Pi to continually track and monitor the progress of my beer all whilst graphing it out to another application. It gets a little geeky!

Please head over to my homebrew website over at Humebrew.com to find out more!

I think Service Workers are pretty cool. They enable us to do so many powerful things with the web today such as intercepting network requests, caching and retrieving resources and delivering push messages to name a few. In fact, I've been running a Service Worker file on this website for around the past four years.

A few years ago, I wrote an article that showed how to determine the Service Worker usage and support for the users that visited your site by pushing statistics to Google Analytics.  It also went a step further and determined if the users were being served cached data through the supported service worker.

It's been almost four years since I started collecting data and I wanted to look back over time and see if there has been any change to the numbers. Let's first start with the overall number - the chart below represents the percentage of users that visit this website that have browsers that support Service Workers. This number includes desktop and all devices (mobiles, tablets).

From the chart above, you can see that between 2019 and 2021 the percentage of users has remained relatively consistent. The numbers for 2022 have jumped considerably, but it's worth pointing out that at the time of writing this article, we are only 3 months into this year. I expect that this number will flatten out over time.

If you click on the second tab in the chart above, you'll notice the number of "controlled" users to the site. In this case it means how many pages were actually controlled by an active service worker. For example, if someone visits a site with a service worker on it, it will get installed the first time and only used the next time they reload the page or navigate away. I wanted to determine how many people were both supported and using my service worker.

You can see from these numbers that over the years it has remained pretty stable around the 25% mark.

As I looked at the data over time, it was clear that the desktop usage has remained pretty stable with very little growth. I wanted to dive a little more into the mobile phone usage on this site and the chart below represents these numbers.

As you can see from the chart above, the number of mobile devices that visit this site that support Service Workers has remained pretty stable. There doesn't seem like much of a story to tell here. While 2022 looks like it has increased a bit, at the time of writing this article, we are only 3 months into this year. I expect these numbers to flatten out.

Of all the data that I managed to collect, I only started to notice a trend when it came to iPhones. The chart below shows the percentage of iPhone users that visited this site that were both supported (and controlled) by a Service Worker.

Apple's Safari browser shipped Service Worker support on their browser a few years ago and it's pretty cool to see the usage increase. There has been a significant increase from 14% in 2019 to around 39% this year (so far).

In terms of the number of iPhone users to this site that are controlled by a Service Worker, this number has remained pretty stable with a slight increase this year.

Summary

While I realise that my website is just a small blog and is in no way indicative of the global trend, it has been pretty cool to see how usage is changing over many years. When I first wrote about Service Worker and PWAs, it seemed like a pipe dream that Apple would even consider adding support, but as you can see from the data, these numbers are trending in the right direction.