Ever followed an OAuth tutorial, copied the code, and then found out the library it uses was deprecated years ago? Yeah, me too. It's frustrating - especially when all you wanted was an access token.

A little while ago I wrote A Modern Guide to Using OAuth 2.0 with C# and Visual Studio Code, and it got a lot more attention than I expected. A few people asked if I could do the same thing for Node.js, so here it is.

This guide walks you through implementing OAuth 2.0 in Node.js using modern libraries and built-in features. No extra HTTP client, no config library - just a handful of lines of code and a working token at the end of it.

Whether you're building a script, a back-end service, or an MCP server that needs to talk to a protected API (more on that in a future post), this is a clean place to start.

On this page

1. Prerequisites
2. Step 1: Create a New Node.js Project
3. Step 2: Install Required Packages
4. Step 3: Configure Your OAuth Settings
5. Step 4: Authenticate and Acquire a Token
6. Step 5: Make an Authenticated API Call
7. Optional: Set up an Entra ID test OAuth App
8. Conclusion

Prerequisites

Before we dive in, make sure you have the following:

• Node.js 22 or later (anything from 20.6 will work for this guide, but I'd go with the current LTS)
• Visual Studio Code
• A basic understanding of HTTP and REST APIs
• A registered OAuth 2.0 application (e.g. via Google, Microsoft, or a custom provider)

Let's get started!

Step 1: Create a New Node.js Project

Open your terminal and run:

mkdir oauth-node-demo
cd oauth-node-demo
npm init -y
npm pkg set type=module

That last line switches the project to ES modules, which means we can use import and top-level await without any extra setup.

Step 2: Install Required Packages

Since I've already got an Entra app setup, we'll use @azure/msal-node to handle the OAuth flow for this example:

npm install @azure/msal-node

That's the only dependency. Node.js 18 and above ships with fetch built in, so we don't need node-fetch or anything else to make API calls. Since Node 20.6 can load .env files natively, we don't need dotenv either.

Step 3: Configure Your OAuth Settings

Create a .env file in the root of your project to store your credentials:

CLIENT_ID=your-client-id
TENANT_ID=your-tenant-id
CLIENT_SECRET=your-client-secret
SCOPES=https://graph.microsoft.com/.default

🔍 What is tenant-id?

This is the unique identifier (GUID) for your Microsoft Entra ID tenant. You can find it in the Azure portal under Microsoft Entra ID > Overview. Alternatively, you can use your domain name (e.g. contoso.onmicrosoft.com) in place of the GUID. This might be different depending on your OAuth provider.

⚠️ Keep your secrets out of source control.

Add .env to your .gitignore before you do anything else. I've seen more than one client secret accidentally pushed to a public repo, and it's not a fun clean-up job.

echo ".env" >> .gitignore

Step 4: Authenticate and Acquire a Token

Create a file called index.js and add the following. It uses the client credentials flow, which is the right choice when your app is calling an API as itself rather than on behalf of a signed-in user:

import { ConfidentialClientApplication } from "@azure/msal-node";

const { CLIENT_ID, TENANT_ID, CLIENT_SECRET, SCOPES } = process.env;

const msalClient = new ConfidentialClientApplication({
  auth: {
    clientId: CLIENT_ID,
    authority: `https://login.microsoftonline.com/${TENANT_ID}`,
    clientSecret: CLIENT_SECRET,
  },
});

const result = await msalClient.acquireTokenByClientCredential({
  scopes: SCOPES.split(","),
});

console.log(`Access Token: ${result.accessToken}`);

Run it with the --env-file flag so Node loads your .env file:

node --env-file=.env index.js

If everything is set up correctly, you'll see a long access token printed to the console. Congratulations - you just authenticated with OAuth 2.0!

A quick note on tokens: MSAL caches them in memory for you, so calling acquireTokenByClientCredential again will return the cached token until it's close to expiring. You don't need to write your own refresh logic for this flow.

Step 5: Make an Authenticated API Call

Now let's use that token to call a protected resource. Add this to the bottom of index.js:

const response = await fetch("https://graph.microsoft.com/v1.0/users", {
  headers: {
    Authorization: `Bearer ${result.accessToken}`,
  },
});

if (!response.ok) {
  throw new Error(`Request failed: ${response.status} ${response.statusText}`);
}

const data = await response.json();
console.log(JSON.stringify(data, null, 2));

✅ Testing endpoint: https://graph.microsoft.com/v1.0/users

This endpoint returns a list of users in your Entra ID tenant. To use it, make sure your app registration has the User.Read.All application permission and that you've granted admin consent.

Run it again:

node --env-file=.env index.js

If all works as expected, you should see a response similar to this:

{
  "@odata.context": "https://graph.microsoft.com/v1.0/$metadata#users",
  "value": [
    {
      "businessPhones": [],
      "displayName": "Dean Hume",
      "givenName": "Dean",
      "jobTitle": null,
      "mail": null,
      "mobilePhone": null,
      "officeLocation": null,
      "preferredLanguage": "en",
      "surname": "Hume",
      "userPrincipalName": "email.com#EXT#@email.onmicrosoft.com",
      "id": "id-response-goes-here"
    }
  ]
}

If you get a 403 instead, it's almost always one of two things - the permission hasn't been added to your app registration, or admin consent hasn't been granted. I've lost more time to that second one than I'd like to admit.

Optional: Set up an Entra ID test OAuth App

This step is optional, as you might want to use your own OAuth provider. However, I wanted to be sure that my code actually worked, so I set up an app in Microsoft Entra ID to test with.

If you'd like to do the same, these resources should help:

• Quickstart: Create a new tenant in Microsoft Entra ID
• Client Id & Secret from Entra ID

Conclusion

OAuth 2.0 doesn't have to be intimidating. With a modern library like MSAL and the features that now ship with Node.js, you can securely authenticate and call a protected API in well under 30 lines of code - and with only one dependency.

Have you run into any OAuth headaches when working with Node.js? I'd love to hear about them in the comments or over on GitHub - and if there's a flow you'd like me to cover next, let me know.

I've been into web performance for as long as I can remember. Back in the day, I cared about it enough to write a book, Fast ASP.NET Websites. My career has since moved into gaming, and while I've kept an eye on web performance, I haven't stayed as up to date as I'd like.

A few of the worst-performing pages on this blog were sitting at a Lighthouse score of 73. I'd been putting off tackling them, but after making some changes to the blog recently, I tried something different: I handed the performance problem to GitHub Copilot, using a mix of Opus and GPT Astra.

I gave AI the Lighthouse output, pointed it at my theme, and asked it to work through the biggest problems first.

I now have a Lighthouse score of 100 on almost all pages including mobile.

It still needs testing on real-world devices, but I've never quite been able to achieve that in the past without a lot of pain.

Where it got it wrong

It didn't get it perfect the first time round, but it did a pretty amazing job. The AI assumed SVG would be the smallest and best image format for many of the pages. It's a reasonable guess - SVGs are brilliant for the right job - but when I actually tested it, AVIF and WebP came out smaller for my images.

AVIF are a new format for me personally, although they have been around for a while and are well supported.

If I hadn't checked, I'd have shipped a slower site and felt very pleased with myself 😂

Smaller images, measured rather than assumed

On other pages, AI suggested that the feature image changed from SVG to PNG so it could go through the image build, which already generated responsive WebP versions.

Rather than assume AVIF would win for every image, the build now compares the files. Every generated AVIF width has to be at least 10% smaller than its WebP equivalent. If any width fails that comparison, the site sticks with WebP for that image.

Where AVIF meets the threshold, a <picture> element offers it to the browser with a WebP fallback. The size comparison happens during the build, so the browser doesn't need to download both formats to decide which to use.

Load the important image first

Smaller files were only part of the work. I also had to think about the order images load in.

On some pages (for example this one), the first image a visitor sees is in the top article card. But it was set to load late, the same as every other image on the page. That meant the most noticeable thing on screen was one of the last things to show up.

The fix was to load that first image straight away and let the rest load as the visitor scrolls. Pages that already have a header image at the top work as before. That first image is a likely candidate for Largest Contentful Paint, or LCP: the metric that tracks when the largest visible image or block of text appears. It's not a good candidate for delaying until later.

The template now gives that image loading="eager" and fetchpriority="high". The remaining cards stay lazy-loaded. If the tag already has a header image, the first card doesn't get that extra priority.

You don't need every image to load fast. You need the one people see first to load fast.

Shorten the font request chain

Lighthouse also flagged a chain of critical requests. For the main font, the browser had to discover the stylesheet, then discover the font through that CSS.

Adding a preload before the stylesheet makes the font discoverable directly from the HTML:

<link rel="preload" href="/inter-latin.woff2"
      as="font" type="font/woff2" crossorigin>

Only the main Inter Latin font gets that preload. The other fonts still load when needed, and font-display: swap stays in place so text can appear in a fallback font while the download completes.

What to take from this

If you've been putting off tricky web performance work on your site, give AI the actual lighthouse report or performance metrics rather than just asking it to "make the site faster". That gives it somewhere useful to start, and gives you specific changes to check.

AI helped me act on performance problems I'd been putting off. The final result still needed a little testing, but I'm really glad with how things turned out!

At Microsoft, we host a global hackathon once a year. It's a great opportunity for people to come together, experiment with ideas, and build things that might make life a little easier.

Hackathons have traditionally attracted people who are comfortable writing code. You might have a designer or subject matter expert on the team, but sooner or later an idea would need to pass through a developer before it became a working feature.

AI is beginning to change that.

For our most recent hackathon, I worked with colleagues in different time zones to build an application using GitHub Copilot coding agents. Some of the people contributing weren't developers, yet they were still able to take an idea, describe the behaviour they wanted, and turn it into working software.

The AI generated the code, but I wouldn't describe what we did as vibe coding.

We had unit tests. We had repository instructions and skills. We worked through pull requests, and we used GitHub Copilot to review the changes before they were merged.

The prompts might have driven the development, but engineering practices kept it on the road. At the end of the Hackathon, I was proud to say that we had a working product that wasn't that far off from launch.

What is prompt-driven development?

This got me thinking about a post that I read lately from Laurie Voss where he suggests how those of us who use AI to build are all product engineers now, whether we like it or not. The cost of writing code has collapsed, and the way we used to produce it no longer exists in the same way it did before AI.

I've been using this term "prompt driven development" for a while now and I feel like it perfectly describes how a lot of modern AI first development takes place.

Prompt-driven development isn't a universally agreed methodology. It's the phrase I've started using to describe the way we worked:

Prompt-driven development uses structured natural-language instructions to direct coding agents, while tests, guardrails, and human review continuously verify the result.

The important part of that definition isn't the prompt. It's everything surrounding it.

If I ask an agent to build a feature and merge whatever it produces without understanding or verifying it, that's much closer to vibe coding. I am trusting the output because it looks plausible and the application appears to work.

In prompt-driven development, the prompt starts the work. It doesn't decide whether the work is finished.

A useful prompt still needs a clear outcome. The repository supplies the coding standards and constraints. Automated tests check the behaviour. A pull request makes the change visible, and a review gives the team another opportunity to find problems.

The AI writes the code inside a system that the team has deliberately designed.

A prompt could be surprisingly simple

During the Hackathon, one of the features we needed was the ability to filter a collection of data. The request was roughly:

Add dropdown filters for location and project.

On its own, that isn't a detailed software specification. It doesn't describe the framework, file structure, naming conventions, test runner, or how the filters should interact.

However, the agent wasn't starting with an empty chat window.

We had already added repository custom instructions that explained how the project should be developed. We also had agent skills that gave Copilot a repeatable workflow for particular tasks.

Most importantly, the project followed test-driven development:

That context turned a short prompt into a constrained task. The agent knew that it couldn't simply add a couple of dropdowns and declare victory. It first needed to express the behaviour in a test, then produce an implementation that satisfied it.

I've previously written about why short AI coding prompts can cost you more time. This experience didn't change my mind about that. A short prompt only worked here because the missing context already existed in the repository.

The real instruction wasn't one sentence. It was the prompt plus the codebase, tests, instructions, and skills.

Building as a distributed team

Our team was spread across different time zones, so we couldn't rely on everyone being online together. The project needed to make sense to somebody arriving several hours after a decision had been made.

Coding agents helped reduce that dependency on real-time collaboration. A team member could describe a feature, ask the agent to implement it, and leave the resulting tests and pull request for the next person to review. The next colleague didn't need a meeting before they could understand what had changed or continue the work.

This didn't remove the need to communicate. It changed where that communication happened.

Instead of knowledge living only in a call or chat message, more of it became part of the repository:

• The prompt recorded the intended outcome.
• The instructions and skills recorded how the agent should work.
• The tests recorded the expected behaviour.
• The pull request recorded what changed and why.
• The review recorded the questions and issues that still needed attention.

That made the repository a shared workspace for both people and agents. It gave us a common source of context when our working hours only partially overlapped.

The tests became a shared safety net

Our tests gave us a shared definition of what the application was supposed to do. When an agent added a feature, it had to preserve the behaviour that was already covered.

This was especially important because not everyone on the team was technical. A colleague didn't need to inspect every implementation detail to see whether a change had broken an existing feature. The test suite gave them an immediate signal.

Tests didn't prove that every change was perfect. They did give both the people and the agents a safer place to work.

Pull requests became our handoff

Instead of allowing agents to change the main branch directly, each piece of work arrived as a pull request. It captured the code, the tests, and the reason for the change in one visible proposal.

We also requested GitHub Copilot code reviews on the pull requests. The reviews picked up real issues and helped us correct them before merging.

For non-technical members of the team, this added another useful layer. They could ask the agent to implement a feature, then use Copilot code review to examine the result. They didn't need to pretend that they understood every line of code, and they weren't limited to accepting the first output the agent produced.

That doesn't mean an AI review makes human review unnecessary. AI-generated code deserves the same scrutiny as any other contribution. However, during a time-limited hackathon, Copilot gave the whole team access to feedback that might otherwise have depended on one technical person being online.

The workflow looked something like this:

1. A team member described the behaviour they wanted.
2. The coding agent created a branch and implemented the change.
3. The repository instructions and skills guided how it worked.
4. Unit tests checked the new and existing behaviour.
5. The agent opened a pull request.
6. Copilot reviewed the change and identified potential issues.
7. We addressed the feedback before merging.

Non-technical didn't mean non-contributing

One of the most interesting parts of the hackathon was seeing how much a non-technical colleague could contribute.

They understood the problem we were trying to solve. They knew what information people needed, which workflows felt awkward, and what useful behaviour should look like. Previously, that knowledge might have been written into a requirement and passed to a developer.

With coding agents, they could express that intent directly.

This didn't suddenly turn every team member into a software engineer, and it didn't remove the value of technical experience. Somebody still needed to create the initial structure, choose the testing approach, and put the guardrails in place.

But once that paved path existed, more people could safely move along it.

I think this is one of the most useful possibilities opened up by coding agents. They don't just help experienced developers write code faster. They can shorten the distance between somebody who understands a problem and a working version of their idea.

Why I don't call this vibe coding

The distinction isn't whether AI wrote some of the code or all of it. In our case, AI generated the code, but that tells you very little about the quality of the development process.

The difference was how we decided to trust a change.

We didn't trust it because the agent sounded confident. We didn't trust it because the interface looked right in a quick demo. We trusted it enough to continue because the expected behaviour had been written down, the tests passed, the existing tests still passed, and the change had gone through a pull request and review.

For me, prompt-driven development has four parts:

Remove the verification and review, and prompt-driven development can quickly collapse into vibe coding with a more professional name.

What I'd take into the next hackathon

The biggest lesson wasn't that AI could generate an entire application. I expected the agents to write code.

What surprised me was how effectively people with different levels of technical experience could work together when the repository contained the right boundaries. The instructions, skills, tests, and pull-request workflow gave us a common way of working, even when we weren't online at the same time.

If I were starting another prompt-driven project, I would establish those foundations before asking an agent to build features:

1. Write down the project's coding and architectural rules.
2. Give agents a repeatable test-driven workflow.
3. Protect the main branch and make changes through pull requests.
4. Run the complete test suite for every change.
5. Use code review, but don't treat an AI review as unquestionable.
6. Make the expected behaviour understandable to technical and non-technical contributors.

AI made our hackathon more accessible, but the guardrails made that access useful. At the end of the hackathon, we had a project that was solid and could actually be used going forward instead of a sloppy vibe coded project.

The AI wrote the code, but the best part was that the team still engineered the application.

There is a particular moment when I meet someone new and they ask what I do for a living.

“I’m a Technical Program Manager.”

You can usually see the follow-up question forming before I’ve finished the sentence.

“Cool. What is a Technical Program Manager?”

If I explain it using words like alignment, execution, stakeholders and cross-functional delivery, their eyes just glaze over. If I say I work with engineers but I’m not an engineer - and that I work on delivery but I’m not quite a producer or project manager - I haven’t exactly cleared things up. Sometimes, I might just say "it's like a technical project manager" and leave it there - but that doesn't feel quite right either.

The difficulty is that Technical Program Manager (TPM) work often sits in the gaps between well-understood jobs. Those gaps are also where some of the most expensive problems begin.

First, what a TPM is not

A TPM is not simply a scrum master, a project tracker with a fancier title, or the person responsible for making sure meetings happen.

Those activities might appear in the job. There may be plans to maintain, meetings to run and actions to chase. However, treating those things as the role is a bit like describing software engineering as typing.

The useful part of the job is not recording that a problem exists. It is understanding the technical and organisational system well enough to spot why the problem exists, who can change it and what needs to happen next.

A TPM finds the gaps between teams

Imagine two engineering teams working toward the same release.

One team owns the build. The other owns the platform integration. Both teams might believe the other is responsible for a certification step. However, when you look at it on separate project plans, everything might look green and on track because neither plan contains a task that appears late.

That's until the project reaches a point where it stops due to no one owning the certification step. The problem isn't that somebody forgot to update a project plan. It's that ownership was never made explicit across the boundary between the teams.

This is where a TPM comes in. They should find that gap before it becomes a release-blocking surprise. That means asking questions that can feel almost annoyingly specific:

• Who owns this step?
• What input do they need?
• When will they receive it?
• What happens if it is late?
• Has the receiving team agreed to the date?
• Is this dependency visible in both teams’ plans, or only assumed in conversation?

None of those questions is technically sophisticated on its own. The skill is knowing where to ask them, understanding the answers and noticing when two reasonable answers do not fit together.

A TPM translates risk into a decision

Technical teams are great at describing technical problems. They might explain that code isn't performant, or a build pipeline has become unreliable, or even that an integration that depends on an API that is still changing.

That does not automatically produce action.

“This code isn't hitting performance targets” may be accurate, but it leaves a senior leader with several unanswered questions. What could it delay? When do we need to decide? What are the options? What does each option cost? Is this something the team can absorb, or does it threaten a committed milestone?

A TPM turns the technical risk into a decision that someone can make:

If the code isn't hitting performance targets by Friday, the integration team will lose its final test window. We can reduce the launch scope now, add engineering support to the team, or accept a likely delay. We need a decision by Wednesday because each option changes next week’s plan.

The TPM has not replaced the engineer’s judgment. They have preserved it, added the missing programme context and made the consequence difficult to ignore.

This works in both directions. Leadership needs a clear account of the risk, while engineers need decisions that are precise enough to act on. “Please prioritise this” is not a useful decision if nobody has said what should move out of the way.

My job has two parts: reactive and proactive

I tend to think of my job as having two parts. One is reactive - responding to problems as they happen. The other is proactive - helping teams prepare for what is coming before it becomes a problem.

An example of the reactive work might be a critical bug passed my way because it crosses team boundaries, needs more investigation, or requires the right people to be pulled in quickly. I might dig into the issue myself, help establish who owns it, or escalate it when the impact or urgency is not yet visible to the people who can act.

The proactive side is quieter but just as important. I spend time educating developers and teams about upcoming features, useful new tools, and changes that could affect how they work. This could take the form of building developer communities, hosting monthly meetings or even larger multi-day Summits.

This could be anything from introducing people to something new that saves them time, to helping them prepare for an upcoming deprecation, or simply making sure they're aware that a tool or service is nearing the end of its supported lifecycle.

If this is done early, it gives teams time to understand the change and plan around it. If it's done late, the same change arrives as another urgent problem.

The two parts reinforce each other. Reactive work shows me where teams are missing context or where ownership is unclear. Proactive work lets me use that knowledge to prevent the same kind of surprise from happening again.

The technical part matters

The word “technical” is not decorative.

A Technical Program Manager does not need to be the strongest engineer in the room, but they do need enough technical depth to ask useful questions and understand why a proposed shortcut may create problems elsewhere.

Without that technical grounding, it is easy to reduce the work to progress reviews. The TPM becomes a messenger carrying updates between people who already understand the problem better.

With that context, I try to help connect the dots across teams. They can see how a technical decision in one area might create a schedule risk somewhere else, or recognise that what looks like a delivery issue is actually an ownership, architecture, or decision-making challenge.

The value is not knowing everything. It is being able to find the right detail and keep the programme-level consequence in view.

So, what does a TPM actually do?

A TPM helps teams deliver complex technical work with fewer surprises. They connect the dots across teams, expose hidden dependencies, and help keep work moving.

Project plans and meetings are all tools for doing that but that is not the job itself. The exact shape of a Technical Program Managers' role varies enormously between companies - and sometimes between teams in the same company. If you are a TPM, Program Manager, Producer or Engineering Leader, I’d be interested to hear your thoughts!

Ever tried to save time by keeping a prompt short - only to spend the next ten minutes answering follow-up questions because the AI didn't have what it needed?

Yeah, me too.

I recently came across a really interesting post from the GitHub Copilot team about making AI coding more cost efficient without sacrificing task quality. One of the ideas that stuck with me was something they called the "local metric trap."

The basic idea is simple: you optimise the bit you can see - one response or tool call - but accidentally make the whole task slower and more expensive.

GitHub found this while testing ways to compress tool output. When useful details were removed, the agent would reopen the original output or rerun the command to find them again. The first response was shorter, but all that recovery work ended up costing more.

GitHub was looking at the machinery inside its agent harness - not studying how developers write prompts. Weirdly, I recognised the same pattern in how I use coding assistants day to day.

Here are a few practical lessons I took from it:

Give the assistant the problem, not just the label

"Fix the bug in payment.js"

Feels nice and efficient, but it leaves most of the useful work for the next message.

Compare that with:

"In payment.js, processRefund() throws TypeError: Cannot read property 'amount' of undefined when a refund is issued for an order with no line items - here's the stack trace."

It takes a little longer to write, but at least the assistant has somewhere useful to start.

Share the real source material when it matters

I'll sometimes describe a function from memory instead of pasting the relevant code: "It takes a request, checks authentication, then saves to the database." The problem is that my tidy little summary can leave out the exact branch or weird input that's causing the bug.

GitHub ran into a similar problem when it tried compressing git diff output. Agents kept reopening the original diff to recover details that had been removed, so GitHub stopped compressing that kind of source-like output. Sometimes the original really is the most efficient version.

Be careful when tidying up your instructions files

If you've got a CLAUDE.md, AGENTS.md, or Copilot instructions file with hard rules in it - don't edit /generated, always run tests before committing - it's tempting to rewrite it so it sounds shorter and punchier.

That can quietly change the behaviour.

GitHub discovered this while shortening its own task-tool guidance. A rewrite accidentally turned flexible advice about parallel agents into a rigid policy, which made independent agents run one at a time. The team stopped the experiment, added a regression test, and eventually found a shorter instruction that kept the behaviour they wanted.

The important bit here is to test what the assistant actually does after changing an instruction - not just whether it can repeat the rule back to you.

Give the full shape of a related task upfront

If you want a pull request review to cover correctness, test coverage, and security, say that at the beginning. Splitting it into three separate requests can add more turns and carry the same working context through the conversation again.

That doesn't mean throwing every unrelated job into one enormous prompt. If the requests depend on the same files and context, batch them together. If they don't, keep them separate.

None of this means that longer prompts are automatically better. It's really about giving the assistant enough useful information to finish the job without having to retrace its steps.

So next time, give the AI what it needs upfront and save yourself the back-and-forth - I hope that helps🚀

When does quality actually get decided on your team?

Most people would say it's decided at the end - the final testing pass, the pre-release bug bash, the last sprint before launch.

I don't think that's true.

The teams I've seen ship the smoothest launches had already decided their quality months earlier. Not through some grand initiative. Through a hundred small habits, built up long before anyone was thinking about a release date.

The problem with treating quality as a phase

Here's the pattern I keep seeing. A team builds a feature, it works, everyone moves on. Weeks later, something breaks it - a network drops, a user signs out mid-flow, a session gets interrupted - and suddenly there's a "quality bug" to fix before launch.

Except it usually isn't a bug. Call it that, and you're saying the behaviour was defined somewhere and someone just built it wrong. Most of the time, nobody defined it at all. What happens if a session drops mid-flow was never written down - it was just assumed, the same way everyone assumes a bridge won't collapse without anyone putting "please don't collapse" in the blueprint.

That distinction matters more than it sounds. "Fix this bug" and "we never actually decided what should happen here" are two different conversations - and only one of them is a five-minute ticket. Calling it a bug is just the easier thing to say. It skips the harder admission: that this behaviour, whatever you want to call it, was never part of the spec in the first place.

That's the trap with treating quality as a phase instead of a habit. By the time you're looking for these problems, you're also under the most pressure to ship - exactly the wrong moment to be having a "wait, was this ever actually defined?" conversation. Every found issue becomes a fire, not a finding.

Think in systems, not features

When you build a feature, it's natural to focus on what it's supposed to do. A login flow logs people in. A save function saves data. A sync service syncs.

But most of the interesting failures live outside that primary purpose. What happens if the network disconnects mid-save? If the laptop lid closes halfway through? If two systems try to sync the same data at once? If someone revokes an API token mid-request?

None of these are exotic. They're the ordinary reality of software running on real machines, on real networks, used by real people who don't behave the way your test script does.

The shift that helps: stop asking "does this feature work?" Start asking "what happens around this feature when things go wrong?" That one question surfaces more real issues than almost anything else I know.

Failure handling is a feature, not an afterthought

A user will never notice a save system that works perfectly. They will absolutely notice one that loses their progress.

The things that go right are invisible and the things that go wrong are the only things anyone remembers. Failure handling isn't a lesser cousin of the "real" feature - it's often the thing that decides whether people trust your product at all.

Building this in doesn't need to be dramatic. Add "what if this fails halfway through?" to your definition of done, right next to "does this meet the acceptance criteria?"

Quality is not one team's job

I get why quality often ends up owned by one group - a QA team, a dedicated tester, a release manager. Someone has to be accountable, and it's tidy to draw the line that way.

But the best outcomes come from readiness being shared, not delegated. Designers think about the journeys users actually take, not just the ones in the spec. Engineers think about what breaks under load. Ops thinks about what happens when a dependency goes down. Everyone brings a different failure mode to the table, and together they cover more ground than any single team could alone.

When quality is "someone else's job," problems surface late - right before a deadline, when there's the least time to fix them properly. When it's everyone's habit, they surface early, while they're still cheap.

"This only works if you have a big team"

I know what some people are thinking - this sounds reasonable for a large, well-resourced org, but not realistic for a small team stretched thin across a dozen priorities.

Fair point, but these habits don't scale with headcount - they scale with attention. A team of three can still ask "what happens if this fails?" in code review. A team of three can still spend twenty minutes a sprint on a lightweight checklist instead of skipping it under pressure. The habit is cheap. It's the absence of it, compounding silently for months, that gets expensive.

Get feedback earlier than feels comfortable

One of the more counterintuitive things I've learned is that teams get the most value from external feedback - a code review, a security scan, a beta test - when they ask for it earlier than feels natural. Most wait until they believe something is "ready." By then, the feedback just confirms what you suspected, instead of reshaping your priorities while there's still time to act.

Whatever your version of a final review looks like, treat an early pass at it as a debugging tool, not a pass/fail exam. The earlier you know where the gaps are, the cheaper they are to close.

A lightweight checklist beats no checklist

Before anything goes out the door, it's worth running a short, boring checklist rather than trusting memory:

1. Deploy it cold. Install or deploy exactly the way it'll happen in production - on a clean machine or fresh container, not your dev box with months of workarounds baked in.
2. Hand it to a stranger. Give it to someone with zero context and no instructions. If they can't reach the core experience without you standing over their shoulder, that's a real finding, not an edge case.
3. Check the paper trail. Make sure the version number, changelog, and docs describe what's actually shipping - not what shipped last time.
4. Retest, don't just re-close. Go back to previously reported bugs and confirm they're actually fixed - and add a regression test for each one, so it can't quietly come back. A ticket marked "resolved" isn't the same as a bug that's gone. Using AI agents for this is a perfect example of how to reduce churn.

None of this is glamorous and all of it prevents avoidable churn later.

The real takeaway

Over the years, I've learned that the teams who dread their final review are usually the ones who've been avoiding the hard questions the whole way through. The teams who walk in relaxed aren't lucky - they've just already asked "what happens when this breaks?" a hundred times before anyone official asked it for them.

That's really the whole idea. The final check was never where quality got decided. It was just where you found out.

So next time you're reviewing a feature, don't just ask if it works. Ask what happens when it doesn't. Do that enough, and your "final" check stops being something you might fail - and starts being a formality that tells you what you already knew. 🙂

A few years ago, I wrote about using a Maturity Matrix to assess software engineering teams. The idea was simple - what does a great team look like, and how honestly can you measure yourself against that picture?

Since then, I've moved into the gaming industry. Anyone who has taken the leap from traditional software development and into game development knows how different it is. Reusing the old matrix just wouldn't work.

I know what some of you are already thinking - games are creative work, not an assembly line, and a maturity matrix sounds like corporate process creeping into art. I'd have said the same thing a couple of years ago. But the crunch numbers, the missed cert dates, and the launch-week crashes tell a different story. Creativity doesn't suffer because a team has good practices. It suffers when nobody has time to be creative because they're firefighting.

So here's the matrix I actually use now - rebuilt from scratch, with the lens I wish I'd had on day one.

What is a Maturity Matrix?

If you're new to the concept - a Maturity Matrix is a list of best practices, and you rate yourself honestly against each one. I like to keep it simple with a Red / Amber / Green system:

• 🔴 Red - this doesn't exist, or we barely think about it
• 🟡 Amber - we do this sometimes, or it's a work in progress
• 🟢 Green - this is something we actively do and do well

The point isn't to feel bad about the reds. It's to give you a clear, honest picture of where to focus your energy. A lot of reds in one area? That's your priority list right there.

I've trimmed this down to the nine that matter most, in my experience - the ones that separate studios that ship well from studios that ship exhausted.

Engineering Practices

Build Pipeline Health

In web development, a slow build is annoying. In game development, a broken build can block an entire team - artists, designers, QA, and engineers all depend on it. I once watched an entire studio lose a full day because nobody could get a playable build out, three days before a milestone review. Are your builds automated and reliable? Are you catching console certification failures early, or discovering them at submission time? A healthy build pipeline is the backbone of a productive studio.

Performance Profiling Culture

Every platform has hard limits - CPU budgets, GPU budgets, memory ceilings. Does your team profile regularly, or only when something starts to hitch two weeks before launch? The best studios treat performance as a first-class feature from the start, not an afterthought you bolt on once the fun is figured out.

Crash Reporting & Telemetry

When a live game crashes, your players notice before you do. Do you have crash reporting in place? Are you tracking telemetry on key gameplay events? Can you identify a root cause quickly, or are you hunting through logs hoping for a clue while your review score drops in real time?

Oh and if you are interested, I wrote an article on the XBOX Game dev blog entitled From Crash to Resolution: A Practical Guide for Xbox & Windows Developers about this very topic.

Game Dev-Specific Practices

These don't really come up on a traditional software team, but they're make-or-break in game development.

Content Pipeline Maturity

This is the game dev equivalent of CI/CD, and it's often overlooked. How quickly can an artist iterate on a texture or a level? How long before a designer's change shows up in a playable build? Slow content pipelines kill creativity and momentum quietly - nobody files a ticket for "iteration felt sluggish," but it shows up in the work. A fast feedback loop is imperative to game dev.

Platform Compliance Readiness

Shipping on console means going through certification, and failing it costs real time and real money. Are you running compliance checks throughout development, or only at submission? The studios that handle this well treat certification like a test suite - run it early, run it often, don't let it be a surprise.

Live Operations Readiness

If you're running a live service game, this one's non-negotiable. Do you have feature flags that let you toggle things without a full patch? Can you push a hotfix quickly without breaking everything else? Do you have a rollback plan, or is "cross our fingers" the plan? Live ops is a discipline in itself, and teams that treat it as an afterthought pay for it at 2am.

Milestone Discipline

Alpha, Beta, Gold (or similar) - do these mean something concrete in your studio, or are they just dates on a calendar? A mature team has clearly defined milestone criteria. Everyone knows what "alpha" means, and everyone knows what still needs to happen before "gold." Vague milestones are how you back into crunch without ever deciding to.

People Practices

This is the category I think studios most underinvest in. Technical excellence matters - but so does the health of the people doing the work.

Sustainable Pace & Crunch Awareness

Crunch is the elephant in the room in game development. Does your team track hours? Is crunch treated as a signal that planning went wrong, or just part of the job - the cost of doing business? The studios with the best long-term output have learned to treat unsustainable pace as a problem to solve, not a badge of honour to hand out at the wrap party.

Cross-Discipline Collaboration

Games are built by engineers, artists, designers, and audio teams, often working on the same systems at the same time. How well do those handoffs work? Are your tools built with non-engineers in mind, or do they assume everyone can read a stack trace? The friction between disciplines is often where time quietly disappears.

How to Use This

Grab a notebook or a spreadsheet and rate yourself honestly against each of these. Don't try to fix everything at once - pick your top two or three reds and make a plan around those first.

If you'd like to make a copy of this spreadsheet for yourself, please head over to this link.

The goal isn't perfection. It's awareness. You can't improve what you don't measure.

The point of this exercise is to have better data and context on how your team works, and what might be their needs. It's also worth mentioning that the list above is a light place to start, you can definitely expand and add more categories!

If you've done this kind of exercise with a software team before, some of these patterns will feel familiar. Teams get good at the things they talk about, and they neglect the things they don't. This matrix is just a way of making sure you're talking about the right things - before your players start talking about them for you. 🎮

Do you remember what a "normal" software team looked like?

A product manager, an engineering manager, a designer, and six or seven engineers. Weekly planning meetings, a backlog to groom, a sprint to run. For most of the last decade, that was just... how teams worked. It was the water we all swam in.

That was my daily life as an software engineer and then an engineering manager for most of my career. That shape was so familiar it felt like a law of nature rather than a design choice.

I recently came across an article on the LeadDev website that argued that traditional team shape is breaking apart - and fast. AI is reshaping the traditional team structure that engineering managers are used to, and the engineering manager (EM) role itself is splitting into two very different futures. One stays close to the code. The other expands outward across multiple teams, with ratios that would have seemed absurd five years ago.

It's a well-argued piece and I agree with most of it. But reading it, I kept thinking: there's a third role sitting right in the middle of this split that barely gets a mention.

The Technical Program Manager (aka a TPM).

I've spent time on both sides of the engineering/management divide. I've been an engineering manager, and I'm an IC now. And one thing that experience teaches you is that the messiest, most overlooked part of any org isn't the people management or the code - it's the space between teams. The dependencies. The cross-functional delivery risks. The "who owns this?" conversations that stall projects for weeks.

That's exactly the space that gets wider as teams shrink.

I know what you're thinking - aren't we just adding extra headcount? Not quite. A single TPM can serve across four or five of those small teams simultaneously, handling the cross-cutting work that would otherwise fragment across every Engineering Manager and tech lead in the building. It's not a new layer. It's a better shape.

That LeadDev article is really describing one thing: small, fast-moving, AI-augmented teams. Tech leads that are head down in the code. Wide-span engineering managers that are spread thin across five or six of those teams. Who's looking at the whole picture? Who's tracking that Team A's output is the input for Team B's Q3 milestone? Who's in the room when the product roadmap and the engineering capacity don't line up?

That work doesn't disappear just because management layers do. If anything, it gets harder.

A good TPM doesn't typically manage teams and doesn't write production code - but they hold the connective tissue of a programme together. They ask the questions that fall between job descriptions. They translate between engineering constraints and business timelines. They're technical enough to smell risk early and organised enough to do something about it.

In a world where your Engineering Manager is managing multiple engineers across multiple teams, the last thing they have time for is running a cross-team dependency log or facilitating a technical risk review. That's not a criticism - it's just scope. Something has to give.

The Technical Program Manager (TPM) fills that gap.

So why isn't this already the obvious answer? Partly because the TPM role itself is poorly understood. Ask ten people what a TPM does and you'll get ten different answers - some companies use the title for someone close to project management, others for a semi-technical lead, others barely use it at all. It's a role that's been historically inconsistent, which makes it easy to overlook when org charts get redrawn. But that inconsistency is also an opportunity - as the Engineering Manager role fractures, companies will need to define this connective-tissue work somehow, and the TPM title is sitting right there, half-formed and ready to be shaped into something more central.

What's interesting is that the skills which make a great TPM are almost the opposite of what each fork of the Engineering Manager role is optimising for. The Tech Lead path doubles down on technical depth. The wide-span Engineering Manager path doubles down on people skills and influence. The Technical Program Manager has to hold both - enough technical credibility to challenge engineering estimates, enough interpersonal range to keep a dozen stakeholders aligned.

If you're currently an Engineering Manager wondering which way to lean as your org flattens, it might be worth asking yourself: which part of the job do you actually find energising? The 1:1s and the career conversations, or the delivery and the cross-team puzzles? Because that second category - that's Technical Program Manager territory, and it might be a better fit than either fork.

And if you're an IC watching all of this from the sidelines, wondering where the growth paths go from here - don't sleep on it. The role is less visible than Engineering Manager and less glamorous than staff engineer, but in a flatter org running lots of small teams, it might just be the most useful person in the building. 🙂

Have you ever walked out of a 1:1 and realised you can't quite remember what you agreed on last time? Or spent five minutes before a catch-up scrolling through Slack threads, trying to piece together a conversation from three weeks ago?

I've been there more times than I'd like to admit. That's exactly why I built Meeting Notes - a lightweight, local-first desktop app for keeping organised notes with the people you work with.

Why I built it

Most of us are using the wrong tool for this. Notion is powerful but noisy. Word and Google Docs works, but it's not really shaped for quick, personal notes. And anything cloud-based means your candid thoughts about a tricky conversation are living on someone else's server.

I wanted something simple and fast. Something that felt less like a productivity system and more like a trusted notebook. No accounts to create, no syncing to worry about, no cloud. Just notes, stored on your machine.

What it does

The app is organised around people, not documents. You add the folks you meet with regularly - their name, role, and team - and every note you take lives under their profile. It builds up a natural history of every conversation over time.

Here's what's included:

• 📝 Track meeting notes for multiple people
• 👥 Manage contacts with names, roles, and teams
• 🏷️ Tag and filter notes by topic (things like hiring, architecture, or follow-up)
• ✍️ Markdown support with live preview and a formatting toolbar
• 🎙️ Voice recording with offline speech-to-text - record your mic and/or system audio and transcribe straight into the note
• 💾 Autosave every 20 keystrokes, so you never lose your work
• 🎨 Light/dark theme
• 💡 Discussion prompts suggested when you start a new note

And everything runs completely offline. Your data never leaves your machine.

The voice transcription feature

This is the one I'm most pleased with. Hit record, have your conversation, and the transcript drops straight into your note - all on-device using the Whisper model. No audio is ever sent anywhere. It even summarises what you discussed. I use it during walking 1:1s and it's become one of those features I didn't know I needed until I had it.

Meeting Notes Desktop App lets you record and summarise using AI

Give it a try

Meeting Notes is free, open source (MIT), and available now for Windows. Head over to the releases page to grab the latest version - just run the installer and you're up and running in under a minute.

👉 **Download Meeting Notes** - v1.2.0 · Windows x64

The source code is on GitHub too, if you want to take a look, contribute, or build it yourself.

If you've got any thoughts or run into anything unexpected, I'd love to hear from you - drop a comment or open an issue. Happy note taking! 🚀

Ever wished your AI assistant actually knew your stuff? Your files, your schedule, or even a custom data source? That's exactly what the Model Context Protocol (MCP) makes possible.

MCP is an open standard for connecting AI assistants like Claude to external data sources and tools. Think of it like a USB port for AI - a single, standardised connector that works with any compatible device. Build the server once, plug it into any MCP-compatible client.

In this guide, we'll build a custom MCP server from scratch using Node.js. The example is deliberately practical: a bin collection reminder system. Simple enough to grasp quickly. Complex enough to cover every core concept you'll need.

What is the Model Context Protocol?

MCP gives AI assistants a common language for talking to the outside world. Instead of every tool needing its own bespoke integration, MCP provides a shared standard.

Your MCP server exposes "tools" - functions that AI Assistants can call. The server does the work (reading files, querying a database, calling an API), then returns structured data. The AI Assistant handles the rest.

Right now, Claude Desktop and VS Code (amongst others) support MCP out of the box. The ecosystem is growing fast.

The Problem We're Solving

To build a basic example (and experiment with real data in my life) - I wanted to create an MCP server that gave me the details of my Bin Collections. I wanted to be able to run a simple chat query and get a response. Ideally, this would save me time logging onto my local council's website and entering my information time and time again.

Here's the scenario. Garden waste goes out fortnightly on Fridays. Recycling is every Saturday. General refuse is also fortnightly on Fridays - but on different weeks. It's surprisingly easy to get wrong, especially when you factor in that holidays throw the schedule off.

So we'll build an MCP server that Claude can query to answer questions like "when are my bins next due out?" A simple use case that's genuinely useful and it teaches you the full pattern.

Setting Up the Project

Create a new Node.js project:

mkdir bin-collection-mcp
cd bin-collection-mcp
npm init -y

You only need one dependency - the official MCP SDK:

npm install @modelcontextprotocol/sdk

Update your package.json to use ES modules. Add "type": "module":

{
  "name": "bin-collection-mcp",
  "version": "1.0.0",
  "description": "MCP server for local bin collection day lookups",
  "type": "module",
  "main": "index.js",
  "dependencies": {
    "@modelcontextprotocol/sdk": "^1.0.0"
  }
}

The Data Structure

Before writing any server code, think about your data. We'll use a simple JSON file - bin-days.json - that stores collection dates:

{
  "collections": [
    {
      "date": "2026-05-29",
      "day": "Friday",
      "types": ["garden"],
      "notes": ""
    },
    {
      "date": "2026-05-30",
      "day": "Saturday",
      "types": ["recycling"],
      "notes": ""
    }
  ],
  "binTypes": {
    "general": {
      "colour": "black",
      "description": "General household refuse"
    },
    "garden": {
      "colour": "brown",
      "description": "Garden waste - grass, leaves, small branches"
    },
    "recycling": {
      "colour": "blue",
      "description": "Paper, card, plastics, tins, glass"
    }
  }
}

Each collection has a date, day name, an array of bin types, and optional notes. The binTypes object describes what each bin is for. Keep it readable - you'll be updating this file manually.

Building the MCP Server

Create index.js. We'll build it in steps.

Step 1 - Import Dependencies and Load Data

#!/usr/bin/env node

import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import {
  CallToolRequestSchema,
  ListToolsRequestSchema,
} from "@modelcontextprotocol/sdk/types.js";
import { readFileSync } from "fs";
import { resolve, dirname } from "path";
import { fileURLToPath } from "url";

const __dirname = dirname(fileURLToPath(import.meta.url));
const BIN_DAYS_PATH = resolve(__dirname, "bin-days.json");

function loadBinDays() {
  const raw = readFileSync(BIN_DAYS_PATH, "utf-8");
  return JSON.parse(raw);
}

The shebang at the top makes the file directly executable. We're loading the JSON synchronously each time it's needed. Not the most efficient approach - but simple, and it means changes to your data file are picked up immediately.

Step 2 - Add Helper Functions

Here's the business logic before we wire up the server:

function getUpcomingCollections(data, daysAhead = 30) {
  const today = new Date();
  today.setHours(0, 0, 0, 0);
  const cutoff = new Date(today);
  cutoff.setDate(cutoff.getDate() + daysAhead);

  return data.collections.filter((c) => {
    const date = new Date(c.date);
    return date >= today && date <= cutoff;
  });
}

function getNextCollection(data, binType) {
  const today = new Date();
  today.setHours(0, 0, 0, 0);

  const upcoming = data.collections
    .filter((c) => {
      const date = new Date(c.date);
      if (date < today) return false;
      if (binType) return c.types.includes(binType.toLowerCase());
      return true;
    })
    .sort((a, b) => new Date(a.date) - new Date(b.date));

  return upcoming[0] || null;
}

getUpcomingCollections returns everything within a date window. getNextCollection finds the soonest one, with an optional filter by bin type. Clean, testable functions. Keep your business logic separate from your server wiring.

Step 3 - Initialise the Server

function createServer() {
  const server = new Server(
    { name: "bin-collection", version: "1.0.0" },
    { capabilities: { tools: {} } }
  );
}

The capabilities object tells clients what your server can do. Here we're saying: this server exposes tools. That's all your AI assistant needs to know upfront.

Step 4 - Define Your Tools

This is where MCP gets interesting. You're essentially writing a contract - here's what I can do, here's what you can ask me:

server.setRequestHandler(ListToolsRequestSchema, async () => ({
    tools: [
      {
        name: "get_upcoming_collections",
        description:
          "Returns all bin collections scheduled in the next N days (default 30). Useful for planning ahead or giving a full schedule overview.",
        inputSchema: {
          type: "object",
          properties: {
            days_ahead: {
              type: "number",
              description:
                "How many days ahead to look for collections (default: 30)",
            },
          },
        },
      },
      {
        name: "get_next_collection",
        description:
          "Returns the next upcoming bin collection, optionally filtered by bin type (general, recycling, garden).",
        inputSchema: {
          type: "object",
          properties: {
            bin_type: {
              type: "string",
              description:
                "Filter by bin type: 'general', 'recycling', or 'garden'. Leave empty for any type.",
              enum: ["general", "recycling", "garden"],
            },
          },
        },
      },
      {
        name: "get_bin_types",
        description:
          "Returns details about each bin type - colour and what can be put in it.",
        inputSchema: {
          type: "object",
          properties: {},
        },
      },
      },
    ],
  }));

Your inputSchema uses JSON Schema to define parameters. The AI assistant reads this to understand what arguments to pass. Notice the enum on bin_type - that tells the AI assistant exactly which values are valid. Good schemas mean fewer errors.

Step 5 - Handle Tool Calls

When the AI assistant actually calls one of your tools, this handler runs:

server.setRequestHandler(CallToolRequestSchema, async (request) => {
    const { name, arguments: args } = request.params;
    const data = loadBinDays();

    if (name === "get_upcoming_collections") {
      const daysAhead = args?.days_ahead ?? 30;
      const collections = getUpcomingCollections(data, daysAhead);

      if (collections.length === 0) {
        return {
          content: [
            {
              type: "text",
              text: `No bin collections found in the next ${daysAhead} days.`,
            },
          ],
        };
      }

      const formatted = collections
        .map((c) => {
          const types = c.types.join(", ");
          const note = c.notes ? ` (${c.notes})` : "";
          return `• ${c.date} (${c.day}): ${types}${note}`;
        })
        .join("\n");

      return {
        content: [
          {
            type: "text",
            text: `Upcoming bin collections (next ${daysAhead} days):\n\n${formatted}`,
          },
        ],
      };
    }

    if (name === "get_next_collection") {
      const binType = args?.bin_type || null;
      const next = getNextCollection(data, binType);

      if (!next) {
        const label = binType ? `${binType} bin` : "any bin";
        return {
          content: [
            {
              type: "text",
              text: `No upcoming collections found for ${label}.`,
            },
          ],
        };
      }

      const types = next.types.join(", ");
      const note = next.notes ? `\nNote: ${next.notes}` : "";
      const label = binType ? `Next ${binType} collection` : "Next collection";

      return {
        content: [
          {
            type: "text",
            text: `${label}: ${next.date} (${next.day})\nBins out: ${types}${note}`,
          },
        ],
      };
    }

    if (name === "get_bin_types") {
      const lines = Object.entries(data.binTypes)
        .map(
          ([key, val]) =>
            `• ${key} (${val.colour} bin): ${val.description}`
        )
        .join("\n");

      return {
        content: [
          {
            type: "text",
            text: `Bin types:\n\n${lines}`,
          },
        ],
      };
    }

Each tool returns a content array with text. You can return images or embedded resources too - but text handles most cases just fine.

Step 6 - Start the Server

const transport = new StdioServerTransport();
await server.connect(transport);
console.error("Bin collection MCP server running");

We're using stdio transport - the server talks via standard input/output. That's why logging goes to console.error. Stdout is reserved for MCP messages.

Testing It

Make the file executable, then run it:

chmod +x index.js
node index.js

You should see "Bin collection MCP server running" in the console. The server is now waiting for requests on stdin. You can also write unit tests against your helper functions directly - they're just plain JavaScript functions.

Connecting to Visual Studio Code

VS Code supports MCP servers through its settings. Open your settings.json (Cmd+Shift+P → "Open User Settings JSON") and add the following:

{
  "mcp": {
    "servers": {
      "bin-collection": {
        "type": "stdio",
        "command": "node",
        "args": [
          "/absolute/path/to/bin-collection-mcp/index.js"
        ]
      }
    }
  }
}

Reload VS Code and your server should be picked up automatically. Then try asking Copilot Chat in agent mode:

• "When are my bins next due out?"
• "Show me all collections in the next 7 days"
• "When is the next recycling collection?"

VS Code calls your tools automatically and gives you a natural language answer. It feels like magic the first time. ✨

The Pattern to Remember

MCP servers always follow the same structure. List your tools. Handle tool calls. Return content. That's it. Once you've got this pattern in your head, you can build servers for anything - your local filesystem, an internal API, a Raspberry Pi sensor, whatever you like.

I took this a step further and deployed this code to an Azure App Service and this made it available from anywhere. The full code for this project is on GitHub. Give it a try - and if you build something interesting with it, I'd love to hear about it.

Over the years, I’ve learned that being a Technical Program Manager (TPM) is a bit of a strange hybrid role. You’re expected to understand the tech well enough to contribute meaningfully, but you’re not the one writing and deploying the code anymore. The best TPMs I’ve worked with are the ones who stay close to the technology - curious enough to dig in, and technical enough to be useful.

The challenge? Tech keeps changing. Super Fast. And in 2026, AI has pretty much woven itself into every part of engineering. Systems are more distributed, products ship faster, and teams expect you to keep up.

A while back, I wrote about how to stay technical as a TPM - the habits, the routines, the mindset. Tinkering with side projects, spinning up local environments, sitting in on design reviews.

Building on from that article, here are the technical skills I’ve found most useful as a TPM in today’s world. These aren’t lofty certifications - just practical things that make your day-to-day easier.

Understand the system

You don't need to design the architecture. But when someone pulls up a diagram, you should be able to follow along.

Start with the basics - APIs, queues, microservices, events, caching. Not so you can lecture anyone, but so the conversation makes sense. Then go one step further: spin up a local dev environment. As I mentioned in the previous post, doing this even once gives you a whole new appreciation for what engineers deal with daily. Dependency hell, environment variables, build steps - the works.

From there, learn enough cloud to be dangerous. Containers, serverless, CI/CD, what "region" and "quota" and "scaling" actually mean in practice. You don't need to run Kubernetes clusters. You just need the vocabulary to keep up - and the instinct to know when something sounds harder than it should be.

Follow the work

This is where a lot of TPMs fall behind - and where the gap between good and great really opens up.

Learn how engineering actually works. Code reviews, branching strategies, feature flags, testing pipelines, linters, release cycles. Not so you can manage them - so you can plan around them. So when an engineer says "that'll need a flag" or "we are code complete", you know exactly what they mean and why it matters.

Get comfortable reading logs and dashboards too. You don't need to be on-call. But poking around metrics when something goes wrong - understanding the shape of a problem before the postmortem - makes you genuinely useful in those moments rather than just present.

And read the docs. Design docs, API Docs, and postmortems. You don't need to absorb every detail. You just need to skim well enough to spot a risk before it becomes a crisis. It's a small habit that compounds fast.

Speak the language

Here's the one that often gets overlooked: learn to read code.

Not write it - read it. Follow a pull request. Understand the logic. Tinker with a small script now and then. In the previous post I mentioned keeping a GitHub account and doing a bit of vibe coding just to stay sharp - this is exactly why. It keeps you connected to the craft in a way that's hard to replicate any other way. And it builds real empathy for engineers doing this every day, under pressure, at pace.

Pick up some basic data fluency while you're at it. Running a small query, calling an API, building a quick graph - these are small things that let you answer questions yourself instead of waiting on someone else every time.

And take AI seriously. Not as a buzzword - as a genuine shift in how engineering teams work. Understanding how your teams actually use it, how it affects velocity, how it changes estimation and debugging - that's table stakes now. Personally, I've found it invaluable when getting up to speed on a new codebase.

The 2026 layer: AI is now part of the system you're managing

This is where I'd add something that wasn't in my original post - because it's genuinely new territory, and most TPMs haven't caught up yet.

AI is no longer just a productivity tool sitting alongside engineering. It's becoming part of the system itself. That changes what you need to know.

Understand AI agent orchestration

Teams aren't just using AI to write code anymore. They're running autonomous agents to handle whole chunks of work - prototyping, testing, triaging, even making decisions. Rather than one massive agent that attempts everything, orchestration coordinates multiple specialised agents, with each one handling what it does best.

As a TPM, you need to understand how these pipelines are structured, where they can fail, and how to think about estimating work when part of the team is an agent. Gartner forecasts that 40% of enterprises will have embedded AI agents by the end of 2026 - this is not a future problem. It's a now problem.

Know what MCP is

Model Context Protocol has quietly become one of the most important standards in AI engineering right now. It's an open-source standard for connecting AI applications to external systems - data sources, tools, workflows - enabling them to access key information and perform tasks. Think of it like a USB-C port for AI. You don't need to build one. But knowing what it is, why teams reach for it, and how it fits into a broader agent architecture puts you ahead of most TPMs right now. Google's explainer is a good place to start.

Rethink how you estimate

AI-assisted teams don't move at the same pace as traditional engineering teams - and the risk profile is different too. Features that used to take two weeks might take two days. But new failure modes appear: hallucinations, evals regressing, model updates breaking behaviour in subtle ways. Your planning instincts need updating. What does a sprint look like when part of the work is being done by an agent? What does "done" mean when the output is probabilistic? These are questions worth sitting with.

Get a basic handle on AI governance

This one is landing on TPM plates fast - especially if you're in a regulated industry or shipping to enterprise customers. In the EU, the AI Act is already phasing in requirements, with broader applicability arriving in 2026. In the US, state-level laws are also emerging.

You don't need to be a compliance expert, but understanding concepts like model versioning, audit trails, bias testing, and what "high-risk AI" means in a regulatory context helps you ask the right questions before they become blockers. This overview from OneTrust is a useful starting point.

One last thought

What's helped me as a TPM is keeping the habits small. Read the PR. Skim the doc. Run the build. Poke the logs. None of it takes long, but it compounds in a way that's hard to explain until you feel it - that moment where you're in a conversation and you actually know what's going on, rather than pattern-matching your way through it.

The AI layer makes this a bit more pressing right now, because the ground is shifting quickly. But the underlying idea is the same one from my previous post - staying technical isn't about being the smartest person in the room. It's just about staying curious enough to be useful.👍

A few weeks ago, I wrote about how PowerToys Workspaces helped me stop wasting time arranging windows every morning. Since then, a few people asked what else I use from the PowerToys suite. So today I want to talk about another tool that's quietly become part of my daily workflow - Advanced Paste.

Have you ever copied something from a webpage, pasted it into a doc, and then spent the next two minutes stripping out all the weird formatting? Bold text that shouldn't be bold, font sizes that don't match, colours that make no sense. Yeah. It's one of those small annoyances that adds up over time.

Advanced Paste fixes that - and a whole lot more.

What is Advanced Paste?

Advanced Paste is a clipboard management tool built into PowerToys. The idea is simple: instead of just pasting whatever is on your clipboard as-is, you get to choose how it gets pasted. Plain text, Markdown, JSON, even as a file - all from a single keyboard shortcut.

Think of it like having a smart clipboard that knows what you actually need, rather than blindly dumping whatever formatting came along for the ride.

You open it with Win + Shift + V by default, and a clean little window appears with your paste options. That's it.

PowerToys Advanced Paste - AI

Paste as Plain Text

This is the one I use most. Copy something from a browser or a rich text editor, hit the shortcut, and paste it as pure unformatted text. No bold. No headings. No leftover HTML weirdness.

It sounds almost too simple - but honestly, that's the point. Removing that friction from something you do dozens of times a day is worth a lot more than it sounds.

You can also set a direct keyboard shortcut for this so you don't even need to open the Advanced Paste window. Just copy, hit your shortcut, and you're done.

Paste as Markdown

Got some HTML on your clipboard and need it in Markdown? Advanced Paste handles that conversion for you automatically. So something like:

<b>Paste</b> <i>as</i> <a href="...">Markdown</a>

Becomes:

**Paste** *as* [Markdown](...)

If you write documentation, blog posts, or work in any tool that uses Markdown - this one will save you a surprising amount of time.

Paste as JSON

Similar idea, but for structured data. If you've got XML or some other structured text on your clipboard and need it in JSON format, Advanced Paste converts it on the fly. No manual reformatting, no copy-pasting into a converter website.

As someone who spends time working across different tools and formats, this one is genuinely useful.

Paste as a File

This is where it gets a bit more interesting. Advanced Paste can take what's on your clipboard and paste it directly as a file - a .txt file, an .html file, or even a .png file for images.

The .html option is particularly handy if you're copying a section of a webpage (links, formatted text, images and all) and want to save it as a proper file rather than lose all that structure.

Image to Text (OCR)

Have you ever needed to copy text from a screenshot or an image? Normally that means manually typing it out, which is tedious at best.

Advanced Paste has a built-in OCR feature that pulls the text straight out of an image on your clipboard. It all runs locally on your machine - no data being sent anywhere. Just copy the image, open Advanced Paste, hit "Image to Text", and the extracted text is ready to paste.

I've used this more times than I expected - screenshots from Teams calls, error messages in images, text in PDFs that won't let you select it. It just works.

Paste with AI 🤖

This is the most powerful feature in the set, and it's worth calling out separately.

If you configure an AI model provider - OpenAI, Azure OpenAI, Mistral, Google, or a local model via Ollama or Foundry Local - you unlock a whole new level of clipboard transformation. You can type a prompt and the AI will reformat or rewrite your clipboard content based on your instructions.

Some examples of what you can do:

• Summarise a long block of text
• Translate text into another language
• Rewrite something in a more professional tone
• Generate code from a description
• Reformat data into a specific structure

The local model options (Ollama, Foundry Local) are worth a look if you'd rather keep everything on your machine and not worry about API costs or data leaving your device.

You can also save your most-used prompts as custom actions and assign them keyboard shortcuts. So if you regularly need to "translate to French and clean up formatting", you can do that in one keypress without even opening the window.

Setting It Up

If you haven't already got PowerToys installed, grab it from the Microsoft Store or via WinGet. Then:

Setting up Powertoys Advanced Paste

1. Open PowerToys Settings and navigate to Advanced Paste.
2. Enable Paste with AI.
3. I added Google's Gemini as a Model Provider. You'll need to enter an API key, but that is easily done depending on your AI Model Provider.

Add an AI model provider

Once you've completed all those steps, it should be working as expected. The default shortcut (Win + Shift + V) is easy to remember - think of it as an upgraded version of the regular paste you already know.

A Small Tool with a Big Impact

I'll be honest - I didn't expect Advanced Paste to become something I reach for every day. But like Workspaces, it's one of those tools that solves a real friction point so well that you quickly forget what life was like without it.

If you're already using PowerToys, enable it today. If you're not using PowerToys yet - what are you waiting for? 😄

The Advanced Paste docs are a great place to explore everything it can do.

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.

A shortcut on my desktop made by PowerToys Workspaces

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!