Matt Lacey - Software Developer

Human questions to ask in code reviews

noreply@blogger.com (Matt Lacey) — Mon, 20 Jul 2026 14:15:25 +0000

Automated (AI) powered code reviews are becoming increasingly popular and powerful. I use them myself to catch things I miss.

But there are questions I ask as a human reviewer that I've yet to see any AI-powered tooling help with.

Questions like:

Does this fix the cause or the symptoms?
Are there related changes that should be addressed while we're in this part of the codebase?
Is this just fixing a problem or actively making things better for the user? (They aren't always the same.)
Do we have related docs or samples that need correcting/updating or adding to?

Is second-order enshittification a thing?

noreply@blogger.com (Matt Lacey) — Wed, 08 Jul 2026 11:00:00 +0000

Enshittifcation, as a term popularized by Cory Doctrow, has for many become a catch-all term for things generally getting worse. I've found it useful (unsurprising if you know me) to think about it in two categories.
There's the popular definition of how very large, dominant platforms change [to get worse] over time as business/organizational priorities change.

I think there's a second-order version of this that follows as a response.

I'd sum it up like this:

"If [big company] doesn't have to focus on quality, we can cut corners there too."

What happens when "everyone" takes this approach is that things get continually worse. Not all at once and not always in the immediately obvious ways. More in the million paper cuts way.

From a software perspective, it's the increasing number of small bugs that no one seems to care about fixing. This teaches people to not bother reporting them. After all, "what's the point? They're not going to fix it even if I [you] do report it."

With fewer known or reported bugs, the company thinks everything is fine, or worse still, thinks skipping on quality is an approach that works.

And a self-reinforcing cycle continues.

I prefer to think of it another way.

Software exists to help people and to make their lives "better". This could be in one or in many ways.

When people are constantly being interrupted, frustrated, and disappointed by the software they use, it's very hard to argue that it is making them better, happier, or more productive.

This is part of the reason I think that QA, customer service, and fixing bugs are among the most important things that those in software development can focus on.

With AI making copying software easier, it's focusing on how it relates to people that can be the real differentiator.

Yes, AI may mean you can vibe code a copy of something that exists, but does it include support for all the non-obvious edge cases? Do you even know all the features that exist in what's being copied? How (and?) will you handle any bug reports?

Yes, building software can be fun for you, but high-quality software that works reliably benefits many more people and, in a small way at least, makes the world a better place.

And this can also lead to mediocrity

A small company tries to compete with a large one. They try to do everything because that's what the large company (or their software) does. They try hard, but as they're stretching themselves so thin, everything suffers. "Never mind", they say, "at least we're trying our best." But, for what? Who benefits? The company's staff exhaust themselves producing a mediocre product, and it's no better than the alternatives.
Trying to compete with a large company and basing goals on the perceived [low] standards of another company doesn't produce a great product, happy customers, or happy staff.

_This was written many months before posting--to avoid anyone thinking I'm responding to a single person, company or incident_

It's probably not an MVP

noreply@blogger.com (Matt Lacey) — Fri, 10 Apr 2026 23:00:00 +0000

It's common for people to refer to early versions of software as MVPs (Minimum Viable Products).

Only, that's not what an MVP is meant to be.

People say:

"ship it early"
"try something out"
"get feedback"
"don't worry about polish"
and "you should be embarrassed about these versions"

But these aren't descriptions of an MVP; they're descriptions of a prototype, and the two are not the same.

A prototype is an early, experimental version intended for getting feedback.

You'll probably use multiple prototypes (or versions of them) until you find an MVP, or confirm that the prototype isn't going to make an MVP.

People tend to focus on the "Minimal" part of the MVP and forget about the rest. If it's not a "Viable Product", then it's not an MVP.

It's not an MVP if there aren't enough people willing to pay for and use it as it is for it to be a sustainable product/business.

Then, once you've proven you've done enough to make it a viable product, then you can add polish, more features, focus on performance or scalability, promote widely, etc.

It's not an MVP if:

It's a free beta version
It's only being tested internally
It includes more features/functionality than are absolutely necessary
You only demonstrate it privately
Your only feedback is from influencers seeing a private preview
People aren't paying for it (or you're not monetising it in other ways)

Of course, there will be some who read this (and probably don't get this far) who will claim that they use the term MVP to mean a prototype. If everyone using the term understands it the same way, then this may not be an issue. But if you start using terms beyond how they were originally defined or intended and you haven't verified that everyone you're communicating with understands this the same way, then there can be confusion, which can lead to wasted time/effort and broken assumptions.

Resetting the experimental instance of Visual Studio has changed in 2026 (v18)

noreply@blogger.com (Matt Lacey) — Wed, 12 Nov 2025 11:24:00 +0000

Updated Jan 7th 2026 -- see below

If you build extensions for Visual Studio, you'll know that sometimes (frequently?--depending on what you're doing) it's necessary to completely reset the experimental instance to get it back to a known/good state.

With previous versions, it was possible to start typing in the main Windows menu and it would find the command to do this for you.

This was possible because the menu included entries for just this command:

(Note that I have multiple entries because I have multiple long-term support versions installed for testing.)

However, VS2026 does not include these menu entries. (Who knows why they were removed...?)

Instead, you can (must) trigger the resetting of the experimental instance from within Visual Studio from within the Feature Search. Simply start typing the command in the search box, and it'll find it for you.

Note. I couldn't find another way to access this functionality in VS2026. If you know of one, please share it.

UPDATE - Jan 7th 2026

I can no longer get the above to work, as the feature search no longer finds the option.
I asked Copilot and it said the only way to do it was via the command line.

Take this with a pinch of salt though, as the above includes incorrect information about the version number as VS2026 is version 18!

Is writing a test a good contribution to an open source project?

noreply@blogger.com (Matt Lacey) — Wed, 27 Aug 2025 19:21:00 +0000

The cliché always used to be that "contributing to docs was a great way to get started in open source." Now I'm also starting to hear people suggest that writing a test can also be a good entry to a project.

But is this a good idea? I'm not sure...

Say you have a piece of code that isn't covered by any tests. It's fair to say this isn't an ideal situation to be in. All things being equal, having tests for this code would be a good (better) thing.

But not all code and not all tests are created equal.

Is adding a test for a piece of code that is never expected to change in the lifetime of the project valuable?

Is it valuable to write tests for code that is so clearly understandable that if anyone changed it, then lots of things would obviously be wrong, and a manual review of the code would easily spot the problem?

Is it valuable to add tests for only some scenarios or paths through a piece of code? Sometimes. Sometimes not.

Is adding tests that ensure all possible input can be handled by the code a good addition? Maybe, but if the project has been around a while, then all such inputs have likely been encountered already. If there were inputs that might cause a problem, they've most likely been encountered and dealt with.

You may be able to create a lot of tests very quickly. (Especially if using AI.) But is it worth running them? If they don't run quickly, is it worth the delays and the money/energy it takes?

Coded tests must also be reviewed like any other code contribution, and reviewing PRs is a common bottleneck in many OS projects.

I'm not against tests.

I think automated tests are great, and everyone should write more of them.

I just think that adding them after the fact is the wrong time to do it. It's harder to do it well, and they risk being low value.
Writing (or at least documenting) all the required tests before you start coding is the best time to write them.

Of course, if there's a project with documented manual test steps and you want to write code to automate them, then that sounds like a very valuable contribution. (Just as long as it doesn't require modifying the underlying code to make that possible.)

Or, if you want to help with the testing of a project, look at some open issues and start documenting how to test those features when they are implemented.

As with any open source project, the best kind of contributions are the ones the owners and maintainers are asking for, and if they're of any size, they never start with a PR but with a discussion or issue.

Miscellaneous AI-related questions

noreply@blogger.com (Matt Lacey) — Thu, 07 Aug 2025 07:52:00 +0000

No answers. "Just", questions I'm aware of and considering:

If working with AI means communicating with machines more like we do with other humans, how do we avoid things also going back the other way and treating people more like machines?
Are "agents the future of [all] work"? And, if not all, how to identify the work that can change or be replaced?
If "AI is only as good as your data", why isn't there as much effort being put into ensuring the quality and accuracy of the data as there is hype about AI?
At what point does AI not need human oversight? All the education highlights human oversight, but the futurists don't include it...
What is in the middle-ground between traditional GUIs and "just" a text box?
As feedback is highlighted as being essential when developing tools with AI, is there a way for feedback from a tool to be passed back to those creating the underlying models?
If there's a GUI for something, does it automatically need (and benefit?) from having an equivalent interface that's accessible via command line, API, and Agent/MCP?
As speed/rate of change is a common complaint among all types of people and people doing disparate tasks, how do you factor this in when introducing AI-powered tools?
If people are generally reluctant to read instructions, why will they happily read the text-based response from an AI tool telling them how to do something?
Asking good questions is hard. How people ask questions of AI-powered tools greatly impacts the quality of results. In training people to use AI, are they also being taught to ask good questions?

Windows Apps London (formerly Windows Phone User Group) - it was good while it lasted

noreply@blogger.com (Matt Lacey) — Wed, 30 Jul 2025 15:06:00 +0000

TLDR: User groups were great. I miss organising and going to them. Maybe I should revisit my plans about this...

I've organized over 100 user group events / meetups. I've also attended and spoken at many others.

The one I had the most to do with was the Windows Phone User Group, which later evolved/became Windows Apps London.

I "ran" this for as long as it existed. It all seems a very long time ago, but as I finish shutting up the virtual shop on the group (Stop paying for things--like domains--that I really don't need and no one looks at) I wanted to take a moment to reflect.

Here are a few of many pieces of similar feedback.

“Great to hear dev thoughts & experiences & see some interesting apps demo’ed”

“Met lots of cool people, and was well worth the trip.”

“Great bunch of people. Lots of enthusiasm and the usual witty banter”

“Meeting was great – fantastic bunch of WP7 developers, designers and officianados!”

“I really enjoyed everyone’s demos; even the games, which is not my domain, provided some interesting info about phone dev.”

“Thanks very much for putting on the event. I found it really useful as well as wonderfully motivating.”

“A great opportunity to meet and socialise with other developers.”

“We had a great time, really informative stuff, we learnt several things both from the talks and from general networking that we’re going to apply to our current and forthcoming projects.”

“Really appreciate the effort put into the event, great to meet everyone”

“It was great being able to network with intellectual individuals”

“It was really awesome. I now have the knowledge to create a better app.”

“It was very informative and enjoyable”

“Fantastic group. Always learn new things and pick up information”

“I like the format where someone knowledgeable us something we didn’t know already”

“One of the most interesting meetings I’ve been to”

“Wealth of knowledge to gain, recommended this to all developers”

“Good format, very useful.”

“Great event! Enjoyed the learning and the interaction with the other participants.”

“Thoroughly enjoyed the evening. Learnt a lot and looking forward to the next one.”

“Lots of fun, excellent talk and great people”

“I think this is a great event necessary for the platform. The atmosphere was good and enabling for sharing ideas.”

“Entertaining and inspiring talk”

“Really enjoyed the format! Great to hear everyone’s thoughts.”

“My mind is pretty blown away right now, very interesting evening with so much to takeaway and think about”

“Probably one of the best groups. Each meeting is useful for learning new things and getting a different point of view”

“Would love to see some more of these events”

“Fantastic presentation. Really helpful to pick up new tips.”

“Interesting conversation was flowing freely around the table. A really good night.”

“Great food, company, conversation and laughs!”

I couldn't let all the history of something that was a big part of my life for a very long time go away completely, so I've created an archive of the website at https://mrlacey.github.io/winappsldn/
Not that I really expect this to be of much interest or use to anyone any more, but it felt too important (to me) to let it go away completely.

Why developers should be excited about implementing migrations

noreply@blogger.com (Matt Lacey) — Mon, 28 Jul 2025 11:39:00 +0000

I often hear that developers aren't keen on doing work to upgrade the frameworks/platforms/tools that they use (or the software they're building is using). It's not writing code, and so it's not considered "real development" work.

I think that doing the work to support upgrades or migrations is one of the most important and valuable things a developer can do:

It's often a simple way to fix potential security vulnerabilities.
It normally brings performance improvements.
Updates bring new capabilities and options for things to add to the software.
Keeping up with the latest versions makes future updates/migrations easier.
It can help you learn and get hands-on experience with the latest technologies.
It can allow you to see a large part of or various/obscure parts of the code base, helping you to learn more about the code you're working on.
It can make it easier for other developers in the team.

So, a high-impact task that helps you learn while supporting the team by doing things they don't want to do? Sounds like a great thing to prioritise if you get the chance.

How quickly can a Windows application launch?

noreply@blogger.com (Matt Lacey) — Fri, 25 Jul 2025 14:34:00 +0000

Following on from my recent post asking How much does start-up time matter when choosing a framework? I've now published some figures and the code I used.

With some minor tweaks, I now have an updated graph of the data:

This graph is based on the release builds of the simplest, most minimal apps I could reasonably come up with that were as close to identical in all frameworks.

The code and more details can be found at https://github.com/mrlacey/WinAppLaunchCompare

From that repo:

Miscellaneous observations:

As expected, WinForms was super fast.
WPF (both .NET and Framework versions) was surprisingly (disappointingly) slow.
The difference between MAUI and WinUI is surprising given MAUI uses WinUI to create the Windows version of apps. I expected these to be closer.
Of the cross-platform options (and WinUI) the difference is basically irrelevant. Having clicked the button to launch the apps many, many times, I didn't perceive any real difference, never feeling that one was slow or faster than the others.

My takeaways:

For choosing a cross-platform framework, there's hardly anything in it in terms of the time it takes to launch the apps.
I wouldn't base a decision to use a particular framework based on these (or similar) tests/results.
I also looked at the time until the App class was loaded. This varied but didn't seem to be related to the overall time taken.
Performing tests like these can easily become an infinite rabbit hole. There are always potential tweaks and optimizations that could be done. If you have such an interest, please go ahead.

Feel free to experiment with this code as you wish and suggest any ways it could be improved or anything artificially slowing down a version of an app can be addressed.

What makes a good teacher of technology?

noreply@blogger.com (Matt Lacey) — Fri, 25 Jul 2025 08:30:00 +0000

I guess it comes down to different people wanting different things. Or, maybe, I'm looking for different things than the majority of people are looking for.

Being aware that I'm trying to learn a variety of new technologies at the moment, and also writing things to try and find a new way of teaching something I'm very familiar with.

Here's what I've seen a lot lately:

Teachers (either qualified educational professionals or people whose job it is to teach and are recognised as experts at teaching new technology) will explain that there are different options or ways of doing things, and then say, "I always use X, so you should too."

Is it that the people learning are just looking for a seemingly authoritative answer, and so are happy to use/do X because they've been told that's ok?

Or, is it that explaining the nuanced differences between options and where/why/how you'd use each and what each is intended/best for is much more difficult and so people don't (or can't) try?

Or a combination of the two?

I find it a bit like being told, "There are lots of potential tools in the toolbox, but I always use a hammer, so you should just use a hammer."

Simple answers are attractive, but don't provide the knowledge to know how to use something other than a hammer or even tell when using a hammer is not appropriate.

I want that deeper knowledge.

Maybe others are happy with a simple solution. When their hammer stops working or can't be used, they'll come back with questions about alternatives.

I prefer to know in advance if I'm going to be using the wrong tool or what the potential negative consequences of what I'm planning will be.

I want all the learning up front. If you're selling education (or views), then holding back some of the knowledge until later has a benefit for you. But, who is the lesson for?