Understability of code should be the default priority

All things being equal, so not when performance is an issue, and in addition to any existing coding conventions, the understandability of code is the most important thing.

Typically this means, "can I read the and easily understand 'everything' about it?"

In the past, I've said that "readability" is the most important thing but what I've realized lately is that I mean: can I easily read it AND understand it?

This is more important than "SOLID principles" or "Clean Code."

Delivering value is the end goal when writing code. The code is a means to an end. It's not an end on its own. The primary goal is not to have code that meets a specific standard. Even if there are appreciable benefits from following that standard. The goal is to benefit the people using the code.

Yes, there are many reasons for following established principles, practices, and conventions. I recommend and follow many myself. But they're not the most important thing.

It doesn't matter how great the code is if you don't ship.

It's great that you've structured code to make it easy to maintain, but if you don't release bug fixes or new features, I question the value of the effort put into how the codebase is structured.

I've seen code that is technically "clean" but is slow and hard to understand and modify.

I recently met some developers at a company who highly prioritize "clean code." But, their shipping schedule was so slow that their customers complained about the infrequency of new features and updates. They had a massive backlog of "core" functionality that was expected to take years to be implemented. Their competitors had more features, more customers, and a better reputation. The developers at this company wanted to create a better product but admitted that their focus on "clean code" meant their development process wasn't as fast as it could be. I'm not implying it's the only issue or factor, but the product, their customers, and ultimately their business weren't as competitive as they could be because of an arbitrary set of rules they were enforcing upon themselves.

Obviously, there are multiple factors to consider when deciding what to prioritize. Priorities will also differ for products, domains, and personal preferences, but having a fixed rule that is never changed can hurt as much as it's designed to help.

Test coverage is also an important related factor. If I'm not writing something "test-first" (because sometimes this isn't practical or desirable), my guiding principle is that anything "non-trivial" should have tests. I define "non-trivial" as anything where I can't look at the code and immediately see and understand every code path and likely error case. It's not always perfect, but it's served me well for years.   

I don't have any "hard and fast rules" for when to play specific practices or when to structure code in specific ways, but "is this easy for me to read and understand?" is my guiding principle. And if I'm working with a team, having code reviews can verify that others working on the code can read and understand it too.

If I can understand it, I'm aware of the potential consequences of any changes, regardless of how it's structured.

I'm curious if others have general principles for planning and structuring code. Anything that doesn't include "must" or "always" (or treats "should" like "must") but instead acknowledges the complexities of managing multiple priorities in different circumstances.

The problem with XAML

Regardless of how you feel about XAML, you'll have a very hard job convincing me it's the best it can be.

What do I mean?

• There's not a lot of (if any) development or investment being done by Microsoft (or other companies) in new and improved tooling that can help people write and work with XAML.
• There have been no real changes in XAML and its capabilities since it came out.
• There's fractured ownership of XAML dialects and tooling within Microsoft. 
• No experimentation or investigation is being done on what can make it better.
• XAML being written today looks (mostly) the same as that written 15+ years ago. 

Think about writing C# code the way you did 15 years ago.

At best, I'd argue that XAML can really only be considered as being at version 2.0.

Imagine if you still had to use version 2.0 of C#. Would that be as pleasant, enjoyable, and productive as you'd like?

As things are, the "problem" with XAML has some consequences:

• Because things haven't changed, there's an expectation that things can't get better. We complain about how bad things are but don't think about improving them.
• Fear of change is common, and a lack of change helps create a self-enforcing feedback loop that means any change is feared even more.
• Because no one is asking questions, it creates an expectation that no one should.
• We get so used to seeing things the same way that it's easy to assume that anything new (or different) is automatically assumed to be wrong. Yes, this is a form of Stockholm Syndrome.

Tens (hundreds?) of thousands of companies are building applications with XAML.

There are millions of apps in existence that use XAML and they are used by even more people, but they're not as easy to write, support, maintain, and improve as they could be.

Why aren't more people talking about how things can be better?

I have ideas about how things can be improved and will share them.

However, I want to be wrong about this.

I want to be wrong about XAML!

I've been rethinking how XAML looks and is written.

It's not controversial to say that XAML has its criticisms.

There are lots of things that can be better about XAML, which will make it easier to write, read, and maintain.

But "everyone" writes XAML the same way.

"Everyone" writes XAML the same way it was written 15+ years ago.

I think things can be better.

I think that we can learn from other languages and ways that software development has changed over the years since XAML was first launched.

I have examples and justifications.

I've been talking at a few user groups and conferences about this, and everyone I've spoken to agrees with me.

But I WANT TO BE WRONG!!!

I don't want to have been doing it poorly for so many years.

I don't want "everyone" to be doing things in a sub-standard way all these years and have so many code bases that could be significantly easier to support and maintain.

I don't want to be the only person thinking about how things can improve.

I'd love to know that the way we write and work with XAML is the best way, and it can't be made better.

But, I don't think I am...

Yes, more on this will follow...

Will AI replace me? - I doubt it

Many times in my career a new technology has come along or an older technology has gone away and people who use the older technology have worried about their future.

What I've always pointed out to those people is that (hopefully) their knowledge goes beyond knowing a specific technology or set of APIs.

An example.

A few months ago I was at a hackathon and came up with the idea of creating a DSL (Domain Specific Language) for creating types/classes.

You write something in English and it generates the C#, Python, or TypeScript.

We got the basics working at the event but it's still an ongoing side project.

On the second (final) day, someone saw what we were doing and wondered if AI could do the same thing.

We gave them a copy of the language spec we'd written (including samples) and they fed it into GPT3.

They could then give it new input and the result was surprisingly accurate. I'd say about 80% of what it produced was correct.

Having already hand-coded an implementation, had I wasted several hours? Perhaps.

But it was only 80% accurate. That's not good enough.

Rather than GPT3, what if we asked ChatGPT to write the code to implement the spec?

That might do better. Also, rather than producing a black box algorithm we'd have some code that I could manually adjust to improve the accuracy.

So would it replace me?

No.

If all I could do was write code to meet a spec, I might be worried, but I can do much more than that.

It couldn't come up with the original idea. I can.

It couldn't write the spec for what it should do. I can.

It couldn't test the accuracy of the output (including knowing if it was correct) and adjust it accordingly. I can.

Yes, there's an argument for not adjusting the generated code but instead providing more input examples to improve the accuracy of what is produced.

But, will that always be the best option? Time will tell, but I can see lots of scenarios where it's much quicker and simpler to manually tweak a generated algorithm rather than write significantly more input examples.

Side thought: Could I create a method signature and multiple test case, then have AI generate an implementation that makes all the tests pass? - It might be a simpler way to write a complex algorithm....?

I try and remember that my ultimate goal is rarely to write code but to provide value as a result of what I create.

If I can create more value by not writing code, or I can create value faster by not writing code then that's a good thing.

I do, however, enjoy the creative act of writing code. I don't think I'll be stopping any time soon. I'm told there's something special about my code: it's easy to read. (I was recently approached about doing some work for someone because they appreciated the readability of my code!)

I've not studied code generated by any AI sufficiently enough to say how readable it is, but I do know that the readability (and therefore understandability) of code is probably the most important thing. Yes, readability is probably even more than being functionaly correct.

Code is read a lot more than it's written. Code also needs to be changed (as bugs are fixed, requirements change, and features are added.) If generated code can't easily be understood, and changed it's just going to produce more problems in the long term.

If you can't read (& understand) the code, it's much harder to know if it is correct. Or change it when you need to.

How often have you encountered systems that were originally built quickly but end up having to be rewritten to add a feature as that's going to be easier/quicker/cheaper than modifying what already exists? I imagine it's more than you want or expect.

I write code so that I can quickly and easily see what it does. I don't want to have to try and remember all the nuances and finer points (I couldn't even if I trie.) Nor do I want to have to repeatedly look at external documents.

When AI can write the code I need in a way that's just as easy to understand, I'll use it.

Ultimately, AI is a tool. Knowing about different tools, how to use them, and what they're good for can improve productivity and the quality of what is produced. You just can't rely on a single tool.

Give a Great First Technical Talk: Share your experiences at user groups and meetups - Available now!

 

My third book is now available on Kindle. It's called: Give a Great First Technical Talk: Share your experiences at user groups and meetups

User groups and meetups are perfect places to gain public speaking experience. They also provide a great way to build professional and personal networks by sharing what you’ve been working on.

This book provides a simple way to give a short talk based on three questions. It’s been used successfully over many years, for many topics, by hundreds of people.

This short guide shows how to use these questions and explains why it works.

For group organizers, the outlined talk structure provides a simple and practical way to build community while encouraging and supporting new speakers.

It's a very short book (about 7000 words) and should take you less than an hour to read.

It's 24 chapters plus an appendix.

Yes, very short chapters. To give you a sample, here are the first two.

Tech Advent Calendars - 2022

It seems that the idea of communities releasing posts on tech topics each day through December is becoming increasingly popular.

Here are the ones I know about

Festive Tech Calendar posts daily articles and videos on various topics.

.NET Advent Calendar posts daily on things related to .NET

.NET MAUI Advent Calendar posts (week) daily about .NET MAUI 

C# Advent Calendar reveals 2 new C# blog posts every day

PowerAdventKalender daily videos about the Power Platform [In German]

WPMarmite  daily WordPress related posts

Related:

Advent of code is a series of small daily programming puzzles.

Know of any others?

.NET MAUI Advent Calendar 2022 - Dec 1st : MAUI App Accelerator

My contribution to the .NET MAUI Advent Calendar 2022 

Get the extension from the Visual Studio Marketplace.

Go to GitHub to give it a star ⭐, become a sponsor, or give feedback.

MAUI App Accelerator v1.1 - Now with C# Markup support

Version 1.1 of MAUI App Accelerator is now available from the Visual Studio Marketplace.

The big change in this version is the inclusion of C# Markup as a 'Coding Style'.

(Other changes are listed in the changelog)

This adds a way of creating the UI entirely in C# and with no XAML.

Ok, that should probably come with a small asterisk, as the generated apps still include XAML files which define the default control styles. I'm not sure if this is the best way to go. Looking at various public projects, it seems there is mixed opinion on doing this. If you have thoughts on what MAA should do, I have an issue open on GitHub where I'd love your feedback. 

Exploring the creation of UI without using XAML has been an enlightening experience. It's caused me to think in new ways about creating the UI. It's also tied in with some of the thinking I've been doing recently about how to improve the way XAML is written.

The overarching thing I've seen when exploring creating UIs this way is that it's a technique that's still in its infancy. There's a lack of established patterns and "best practices." Lots of what I thought of as basic, core functionality is missing. There's a lack of consistency and conventions is how people create UIs this way. Also, lots of what I've seen seems to be based on ways of recreating in C# what would otherwise have been done in XAML. This seems to be missing out on some of the potential benefits of not using XAML. When writing C# to create a UI, I find I want to do things very differently from how I would in XAML, but I don't yet know if that would have any currently unforeseen consequences or be too hard for others to understand.

The UI code generated by MAA is still very simple. It's this way, so it's easy to remove (for those needing something different in their app) and understand for those who are learning--or want to know what can/can't/should/shouldn't be removed. 

I strongly suspect that people creating UIs with C# in a couple of years will be doing it differently from how I see it being done today.

I'll continue to watch the MAUI.Markup and CSharpForMarkup repositories, and hope to learn from them as more people start creating UIs this way.

Give a great first technical talk - Table of Contents

Want to know more about the book I'm writing about helping people give their first technical talk at a user group or meetup?

Here's the Table of Contents.

Hopefully, it gives you a good idea of what to expect 

• Why give a technical talk?
• You are not going to give a talk like you’ve seen many times before
• You only need to answer 3 simple questions
• Question 1. What did you make (or do)?
• Question 2. Why did you do (or make) it?
• Question 3. What did you learn from the experience?
• Shorter talks are better
• Anyone can give a talk
• Your experiences (whatever they are) qualify you to speak
• You speak for the audience’s benefit
• You’ll get a lot out of speaking too
• You already know everything you need to do this
• You are telling a story
• You are not the hero of this story
• You don’t need to say everything
• You want questions and discussion--and there will be some
• You are not there to sell anything
• You have nothing to fear. You are among friends
• Your nerves are a good thing
• You only need to do very minimal preparation
• Do not start with PowerPoint (or Keynote)
• Your first technical talk is just the start
• Show and tell me how you get on
• Help others give great technical talks too
• Appendix 1. – Examples of talks given
• Appendix 2. – Advice for meetup organizers
• Appendix 3. – Advice for developer evangelists and marketers

Yes, there are a lot of chapters, but they're all very short.

More details to follow.....

What I learned from 14 years of organizing user groups and meetups

I'm unsure about my future involvement with organizing meetups and user groups.

However, I do know that over those years, I've learned a bunch of things that might be useful to other people who organize, attend, and/or speak at them.

There are 4 key components to organizing a meetup/user group

1. Finding a venue
2. Organizing speakers
3. Telling people about upcoming meetings and persuading them to attend
4. Running the actual event.

I can't help you with the first component but can do something for the others.

I think the key to creating a strong community where people want to attend regularly is to get attendees to talk about what they've worked on.

Over the years, the most requested subject for talks has been to hear from others about what they've made and what they learned in the process.
Introductions to technologies and basic demos have their place but seeing actual projects and hearing about overcoming the challenges of creating them can be much more interesting and informative. They also have the possibility of providing unique information. Such talks aren't the things you can hear anywhere else and are unlikely to be something you can find a video of online.

Having these talks has a few potential benefits:

• It provides more unique speakers.
• It provides unique content.
• It allows an opportunity to hear from peers.

That all sounds good, but how do you find people to share such experiences?

Well, as part of an event, as an organizer, I'm going to try and talk to as many attendees as possible. Not only is making people feel welcome part of my role as host, finding people with things in common and connecting them with others is much more likely to make them come again. It also gives me a chance to ask people what they've been working on. Then, if they've been doing something I think might be of interest to the group, I ask them if they'd be up for giving a short talk about it at a future meeting.

This simple behavior helps build connection amongst attendees which increases the likelihood that they'll come again, and it helps find interesting new speakers.

It's simple, and it works.

But giving a talk can be intimidating and a lot of preparation. So I don't ask people to do that. I ask them to spend five minutes answering three simple questions.
It takes minimal preparation, is easy to do, and produces great results.

It's been so successful that it's enabled over 100 people to give such talks.

This is the unique insight that I discovered, and I think is valuable to other group organizers.

So, I've written a short book about it.

It's going to be called: 

Give a Great First Technical Talk - Share your experiences at user groups and meetups

More details to follow soon.

The sound of a goat bleating....

... it sounds a bit like "maa" - doesn't it?

And as I've been abbreviating MAUI App Accelerator as "MAA", I thought a goat icon would be a nice idea.

Template Studio for .NET MAUI

 Except it's not called that.

Introducing MAUI App Accelerator.

It's a Visual Studio extension that helps accelerate the creation of new .NET MAUI applications.

After installing the extension, when you create a new app and after specifying the name and location for the project/solution, a 5-step wizard is displayed that allows you to include the pages, features, and functionality that you want.

The goal is to make it simpler and faster to get started with the app you want. It does this by reducing the amount you have to delete from a newly created project and adding more things you want to add. It should save you lots of time when creating a new app and help provide a structure to the codebase that will help you on the path to success.

As a bonus, it also allows you to see different features, functionality, and ways of writing code

There are lots more features and options I want to add.

Some of these ideas are documented on GitHub. Please add issues with any ideas you have of things you think should be included.

My GitHub sponsors helped make this possible. You can see some of them (i.e. not the ones who made their sponsorship private) credited in the wizard. 

If this is helpful and you want to help support more development, please consider becoming a sponsor.

And as a bonus, I created this little goat icon for it. :)

Modernizing Your Windows Applications with the Windows App SDK and WinUI - Review

 

Note. I was provided a copy of this book for review purposes. ;)

This is the best book on the Windows App SDK there is.

Ok, pull-quote provided (and yes, this is the only book on the topic I'm aware of); let's get into some details.

While there's lots of helpful information in the book, and I learned some things, I still have some confusion.

To be fair, much of this is the fault of the WinAppSDK and not the book. Some things just aren't clearly defined. Microsoft's documentation and video explainers haven't cleared things up for me. Therefore, it's not fair to pick on this book for not being able to clearly explain something that just isn't easily definable.

That the book seems to confuse WinUI3 and WinAppSDK (or use them interchangeably) in places seems par for the course when it comes to this distinction. :( 

Additionally, things in the book feel like padding to make the WinAppSDK seem like it contains more than it does. I assume they're not included to pad the book (which has over 500 pages) but rather to make the book give the impression that there is more in the WinAppSDK than there is. For example, WinML and AI aren't specific to the WinAppSDK, and so a chapter on them seems out of place, or at least unnecessary, here. Combined with the WinAppSDK features that warrant only a basic description but no real detail or insight from the author magnifies the issue for me.

This book does what many technical books try and do, that's trying to sell the technology. I doubt many people buy a technical book to see what's possible with the technology, as many websites will give you the comparison for free. What's much more useful (in my opinion) is examples that show real-world scenarios. Compared to basic demos or vague descriptions of what to do and then pointing to the official documentation for more details. Where a book can go beyond the basics and show gotchas and tips for things developers are likely to encounter, it's much more valuable and for longer.

One concern I had about the book was how up-to-date it could be given; how close it came out to the release of a significant update; how long it takes to write a book; and the fact I've taken several months to finish reading it.

This is always an issue of printed books, and it's noticeable here. References to ".NET 5 or above" as the version to target when .NET 5 was out of support when the book was released are potentially concerning. There are also things claimed in the book that I thought are no longer the case. I now need to go and check myself.

Many code examples also don't take advantage of the latest C# language features. This leads to code that isn't as concise as it could be and distracts from what the book is trying to teach/show. In a book that's supposed to be about modernization, this stands out.

So, what can I tell you if you want to read this book (and if you want to know everything you can about the WinAppSDK, you probably should)?

If you're going to clone the repo with the sample code, beware of the very long repository name. Avoid the root of a drive to avoid MAXPATH issues.

Use the sample code repository to look at the code samples. This will help avoid issues with inconsistently formatted (& indented) code, long code samples that span over pages, and the typos I noticed (hopefully now fixed in the repo.)

Don't skip chapters. Read the whole thing. It says early on that you can skip the chapters that aren't relevant. The theory is that if you have a background in WPF and don't know anything about WinForms, you can skip the Winforms chapter. However, the WPF chapter refers to comments in the WinForms chapter, and the UWP chapter refers to the WPF one. I started by skipping on to what was supposed to be relevant to me but found it made much more sense when I went back and read everything in order.

I wanted the section "Building a Future-Proof Architecture" to be more than a brief introduction to the MVVM pattern. I've seen (and inherited) some very poorly put-together solutions that used this pattern. It seems particularly odd to have/need this chapter for all the developers coming to WinAppSDK from WPF or UWP (or Xamarin.Forms.) Although I'd probably note such a chapter as conspicuous in its absence if it wasn't included.

Similarly, I was concerned about the frequent references to the "proper way" of doing things. Almost all development frameworks, platforms, and SDK are nuanced enough that there is no single way of doing something right for all situations and circumstances. But, at 500+ pages already, I assume there wasn't the space to go into more details. :(

I know this might come across as a negative review, but I don't think that's a result of the book. It probably says more about me and my opinion of using printed books to try and communicate information about a new technology that is changing rapidly and the need for a publisher to get books out quickly.

There's gold in there if you dig for it, though. Such as the advice against using the built-in localization functionality. I definitely learned things from this book.

Laughter and creativity - Peter Pendleton Eckersley

It cannot be more sufficiently emphasized that, that pioneer adventure was born in laughter, was nurtured in laughter, and died in laughter.

And I want to believe that if only people would see their jobs; if only people would see their lives in terms of its humor, of its excitement, and that a job well done deserves laughter.

Not the solemnity of the pompous administrator on top of it.

If we could only see that the thing that we do is a God-given thing, for heaven's sake,  because it's creative and it's fun and it's exciting.

Then, I think, all these certificates, all these rules, all these rather dull regulations might be seen to be unnecessary.

Peter Pendelton Eckersley - on the bureaucracy that came at the start of the BBC

Plant trees while you search for error descriptions

 

Ecosia is a search engine that uses some of the money they make from selling advertising to plant trees. You make a small change to your search behavior and they plant some trees. It's simple.

There's even an extension for Chrome to make it your default search engine. (You should install it 😉)

Under the hood it uses Bing to provide the search results, so you'll still get high-quality results. This isn't some random, small company trying to compete with Google on Search.

That all sounds good, but I've done a bad thing.

I've changed a default setting.

Shock. Horror!

For my Error Helper extension for Visual Studio, the default is now (as of v2.4) to search with Ecosia.

Changing default settings is something you should only do with great care and for very good reason as it can surprise, confuse, and frustrate the people using the software.

If you're not aware of my extension, it provides some additional options when you right-click on an entry in the Error List. The one of particular interest here is the option to easily search for the text of the error message. Sometimes, error messages don't give you all the information you need to address an issue and so it's necessary to ask the internet for help.

But I did it for a very good reason.

I wanted to help raise awareness of Ecosia, and in turn, help create a world with more trees in it.

This will help plant a few trees based on usage and people not even realizing anything's changed.

The impact on existing users of the extension will be minimal as it will continue using whatever they were using with the previous version. Even if that was the old default.

I'm just trying to do something to help other people make the world a slightly better place with minimal effort on their part.

Don't want this? That's ok, you can still configure the extension to use, Bing, Google, or StackOverflow as the search engine of choice.

If you're very upset by this, simply send me your receipt for your purchase of the extension and I'll give you a full refund. (Just kidding, the extension is free!)

Creating binary logs from Visual Studio

 [Again, this is mostly for my own reference, so I can find the link again quickly in the future]

It's possible (and well documented) to save detailed and binary log files when compiling code with MSBuild.

But, if you are getting different results when using MSBuild and Visual Studio, it isn't as easy to create the equivalent logs from Visual Studio.

Well, my search-fu may not always find it, but there is a way to do this. Details at https://github.com/dotnet/project-system-tools#getting-higher-fidelity-logs-from-vs-vs2022-onwards 

Testing against old versions of Visual Studio

[This is mostly for my own reference, so I can find the link again quickly in the future]

If developing Visual Studio extensions, it can sometimes be useful (and necessary) to have different versions of Visual Studio installed.

Previously I achieved this by having preview and non-preview versions installed and being careful about how and when I updated them to newer versions.

However, I recently had to also test against a version older than I had installed on any of my machines.

Well, it seems the lovely people on the Visual Studio team already have this scenario covered.

It's possible to get older versions of VS that don't prompt for updates. This allows the installation of multiple versions on the same machine without having to worry about updating them.

Get them from:

https://docs.microsoft.com/en-us/visualstudio/releases/2022/release-history#fixed-version-bootstrappers

Why a bug fix should "always" include new tests

Ok, maybe not always, but please don't start by assuming you're the exception.

(Note that exceptions should come with an adequate, documented explanation.)

So, imagine the scenario: You find something wrong in the code base, so you fix it.

Simple enough and almost certainly a good thing. 

But, consider the bigger goal that we don't just want a codebase with fewer bugs in it we also want a codebase that is easy to maintain, so that future bugs or changes (there will be some) are also easy (and quick) to address.

By adding or changing code without adding tests, we risk making future changes harder/slower.

Going back to the bug you fixed. How was it discovered? I'm going to assume it wasn't because of a failing test.

It was probably found by someone using the code/app/service/whatever or looking at the code. Either way, a manual process.

And how was the change tested? Again, I'm guessing manually.

So what happens when someone has to change something near or related to that code again in the future?

They'll have to test it manually again. But, also, they need to work out (or remember) how to test it manually and work out what all the scenarios they need to test are. Then they have to do that testing in its entirety and without human error. This is unlikely to be fast, thorough, or accurate.

But, also, what if the place where the error in the code was found wasn't the only place that error had been made? Have you really, manually reviewed the entire codebase to look for such an error? How do you know that you really checked *everywhere*? Was that a good use of your time? Additionally, how will you make sure that any future changes to the code don't reintroduce the same bug? Either here or in another part of the codebase? Are you really going to add that to the list of manual checks that are made as part of every code review? I suspect not.

Suddenly, taking the effort to write some automated tests doesn't seem like such a waste of time. Doing so can often be faster than manually retesting something while working on it. Also, having something that checks your code for bad practices, inconsistencies, and anti-patterns is much faster than manually reviewing all but the smallest codebases.

But, what if you don't know how to write tests? Or you don't know how to write a good test for this specific scenario? Well, you find out. Ignorance isn't an excuse.
If working on a codebase as part of a team, ask them. Your whole team wants to work together to create better software and that includes having a codebase that is easy and better for them all to work with.

Maybe I'll write more on getting started with testing or testing difficult things in the future. Don't worry, though; there are a lot of resources about this already on the internet (& elsewhere).

<RantOver />

Why some things never get better

So, imagine you're dealing with a technical problem. 

There's no specific tooling to help with your scenario.

You can muddle through but everything feels harder than you'd like. 

There are a few simple tools or features that would make this much easier. They'd handle the need to do complicated things manually and avoid errors that are easily made when doing things manually.

But, this thing you thought was going to be easy has turned out to be harder and more time-consuming than you had planned for.

You're now frustrated and behind. 

You just need to get this done and move onto the next thing.

You can't justify the time to work on tooling as well as solving the problem immediately in front of you.

The whole thing has become so frustrating that you just want to get it fixed so you can move onto the next task and not have to think about it again.

You certainly don't want to spend more time thinking deeply about the issue. As would be needed if building a tool to help with it.

So you move on to the next thing.

Maybe, you think, you'll come back to this once the initial pain has passed and work on the tooling that will be useful for yourself in the future and for other people too.

But you're busy.

Other things have a higher priority. Plus, you can't fully remember the pain you felt previously. Maybe it wasn't that bad. Maybe someone else will have made something to help when you have to work on something similar in the future.

And so you don't create that tool.

Sometimes things only get better when you take it upon yourself to deal with extra pain so that others don't have to.

Sadly, I'm not able to handle as much of that extra pain or as frequently as I'd like. :(

</rant>

There are two types of developers

There are two types of developers:

• Those who test their code before checking it in.
• Those who check in code and rely on automated checks as part of a PR to do the testing.

(and possibly others, but beyond this discussion.)

I'm not going to argue that one is wrong and one is right. 

What I do think is important to remember is that if you have a team that contains a mixture of the two types they (you?) need to be aware of how they are likely to think about each other and there is the possibility of conflict because of this.

Those who test before committing their changes think of themselves as being thorough. They may think that those who don't do the same are not as concerned about the quality of the code and the product it is part of. They may also think that others don't think testing is important or is something that other people can deal with.

People who rely on automated checks to do all the work, may think that those who don't do the same are not being efficient with their time. In fact, they may think that those who do run all the tests before committing their work are wasting their time, and ultimately providing less value to the team as they spend time running tests rather than writing code.

The takeaway here is to know who in your team fits into the two types. Where you have people with different ideas on this topic, acknowledge, accept, and appreciate the differences. Having everyone in a team think the same way isn't a good thing. Appreciate differences. Recognize that different doesn't mean wrong. Instead, focus on how everyone contributes and brings unique value.

How you should be using (and naming) resources in XAML

... because a lot of people get it wrong!

We'll get to XAML shortly, but let's start by looking at some C# code:

It seems like a reasonable method, with an appropriate name. Doesn't it?
The name of the function clearly explains what the code does. That's a good thing. Right?

Imagine that the above was created to add a tax to a price. (This is a simplified example where tax is always the same and you can ignore the complexities of tax in the real world.) Now, is the function well named?

Think about where this method might be called from.
Will it always be evident to someone looking at the code why 20% is added to a price?
What if there were other reasons in the codebase to add 20% to a value. What's to stop them from using this function in those places too?

I asked if the above method was well named because it describes what the code does? Actually, this is a lousy way to name something.

The name should indicate the intent behind the code and suggest why it does what it does. We don't need the name to tell us what the code does. We want it to tell us what it is for. This means the name doesn't need to change when the code changes, and it clearly indicates where and why it should be used.

If we have the AddTwentyPercent method in our codebase and it is used for something other than calculating tax, what happens when the percentage for sales tax changes?

If we only change the contents of the function, we end up with something whose name does not describe what it does. Not only does it not describe it, but it also does something different. Something that could easily be misunderstood and end up with code that doesn't do what is expected or wanted. Code that is hard to reason about ("I know it says add twenty percent, but I need to remember that it actually adds 22%") and code that is harder to maintain because anyone unfamiliar with this "special case" could think it does what the name suggests.

If the tax rate changed, we could respond to this by creating a new function called--for example--'AddTwentyTwoPercent' and changing the calls to the old method related to adding the tax amount to call the new function. But how would we know which of the places that used the original function were to do with calculating tax? We'd have to go through and check them all.
We wanted to make a change to the percentage used to calculate tax. This should mean changing a single value in one place. However, we're now having to potentially review lots of code in various parts of a codebase. It should be a simple change, but a poorly named function has made this task much more complicated, time-consuming, and therefore also expensive.

Instead, what if the function had initially been named 'AddTaxToPrice'?

In that case, it would be clear what it does and where/why to use it. It should also raise a red flag if it was used for something else that happened to need to add an amount to a number that coincided with the tax percentage at that time.
If we had a function with the 'AddTaxToPrice' name, we could confidently change the contents of the function without needing to worry about where it was used or whether the name needed to be changed.
We'd have encapsulated the logic in a single place, with only a single reason to change, and minimized the chance for confusion about what the code does.

Now let's think about XAML.

Consider the following:

This might seem like a reasonable name for a resource. You may have even seen this in code presented as an example of "best practice." I actually think this is a terrible way to name a defined resource and consider it an anti-pattern. (i.e., an example of something you should NOT do.)

There are issues with this that are comparable with the C# function discussed above in the following negative ways.

1. The name matches what the code does.
2. The name does not indicate where or why it should be used.
3. The code (thickness) could easily be used in very different places and for other purposes.
4. If one of the places where this style was used needed to be changed, we'd have all the same problems as with the C# function. 

Imagine this thickness is used as the margin for Grids containing the contents of most pages in an app.
Now imagine you want to make a change to the app's design, so you have a large margin on the right-hand side of each page and add a smaller margin to the bottom of the content on each page. What do you do?

• If you change the value of the existing resource but not the name, you get something with a name that doesn't match what it does. This leads to potential confusion for anyone (likely including yourself) reading the code in the future.
• You could create a new resource and change all references to the old name to the new one. But, this means reviewing all uses of the original resource and only updating the appropriate ones. This could be a lot of work.

Imagine instead that a resource with the name 'StandardPageContentsMargin' had been created.

• The exact details of this could be changed without the need to rename anything.
• The resource's details could be changed without worrying about unexpected side effects.
• It would be obviously wrong if someone tried to use the resource for something else. (Such as another type of control or place within the UI.)
• You wouldn't waste time in an unnecessarily complicated and hard-to-maintain codebase.

In software development, how you name things matters. Yes, even in XAML.

Give resources names that indicate what they are for and where they should be used.

This will give you XAML code that is easier to write, review, understand, and change.

Yes, this might mean you end up creating multiple resources with the same contents/value but different names. No, the current tooling does not do a lot to help with creating similar resources. But that doesn't mean you shouldn't do it.

But, the "best practice" examples do the bad thing? - Yes, and we (I) shall (will) change them!

Some notes for people giving technical talks

At a point last year (that I'm not going to identify) I got very frustrated with the way many people were giving technical talks. 

This is a list I put together at that time with some important things for anyone giving a technical talk to remember.

It's not about the speaker. We don't need to hear their biography or life story.

Tell a story. Or, at the very least, give the impression that you have a structure and it's not an arbitrary collection of things in an arbitrary order.

The talk is not an abstract thing. Don't talk about the presentation you're giving as an external thing. Especially not as something you have no control or influence over. It's YOU giving a talk. The talk doesn't exist separately from you.  

Don't give a talk anyone can give. Let others do that. Give the talk that only you can do.

No excuses: rehearse, rehearse, rehearse & get timings right. If you run out of time it shows you weren't prepared and therefore are happy to waste everyone's time and not give them what you promised.

If online - look at the camera. If you've chosen to have a camera on you, look at it. We don't want to see you looking above, below, or beside the camera. We really don't want to see the side of your head. 

If in-person - look at the audience. Not at the screen. Not at your laptop. Not at the floor. Not at the ceiling.

Put key names and terms on the screen (not just logos.) The audience might not recognize a logo or a term you mention. If they want to look up more about it later, it really helps if they know how to spell it. 

Share the resources. Don't say you will and then not do it. And make sure you share them everywhere the talk is made available. If you don't know then ask the organizers where it will be.

Have short versions for all URLs. Don't put a long URL on the screen and hope that someone in the audience will be able to read or accurately copy it.

Have a really clear title that matches the talk. Don't mislead an audience to attend by letting them think a talk is about one thing when it's actually about another. This includes using broad terms when you're actually going to be talking about something very focused. 

Do something specific to the audience/situation. No one wants the same thing repeated verbatim somewhere else.

whining over ;)

Matt's Template Studio for UWP, WPF, & WinUI (C#)

 

I'm still busy migrating my experimental port of Windows Template Studio of Visual Studio 2022 to the official repo. (See the progress here.)

In the meantime, today I've released updates for my versions of the extensions. Please download and try them out. Help me find any last bugs or issues. These latest versions include lots of bug fixes and improvements. My versions will be where I try out new ideas and provide features and options that aren't likely to ever end up in the official Windows/Microsoft version.

To help distinguish my versions from the soon-to-be-released official versions, I've renamed my versions. Hopefully, this will avoid any possible confusion and help more people realize the effort I've put into this. (Lots of people think I'm being paid by Microsoft to do this.)

These wonderful people helped make this possible. Will you consider joining them?

What's wrong with this WinUI code?

Here's some simple code.

There are probably many ways you can see that it could be different, but there's one major potential problem with this code. Can you see what it is?

private async Task OpenInBrowserAsync(Uri uri)
{
    await Windows.System.Launcher.LaunchUriAsync(uri);
}

The problem with this code is that it contains an unprotected "seam" between the code that's part of this codebase/application and code that isn't.

I'm going to use "your code" to mean the code that's written by you and "other code" for everything else.

Anywhere there's a place where your code meets other code, it creates a seam. A seam is where there's a potential weakness. When two things are connected or joined together, there's a potential for problems. It's where defects or issues are most likely to surface.

Let's go back to the code above. When LaunchUriAsync() is called, three things could happen.

1. The URI could be opened in the default browser. This is what is expected and will hopefully occur most of the time.
2. There could be an exception thrown by the other code.
3. Something could happen that means the provided URI can't be opened, but no exception is thrown.

(Yes, other possibilities exist but won't be covered here.)

Scenario 1 is the easiest to think about. Everything works as expected, so we don't need to discuss this further.

Scenario 2 is vital to consider as it's likely to have a significant negative impact on the people using your app. Hopefully, it'll never happen, but it's always a possibility. You don't want other code to cause your app to crash. The people using it will still blame you. That an exception has its source in other code doesn't matter. That any potential exception is also coming from async code has the potential to increase the possibility that the exception could crash the whole app. Handling the potential for other code to throw an exception is essential!

Scenario 3 is easy to overlook. That code "works" or throws an exception is easy to appreciate. That there's a middle ground--where it "works" but not as expected--can be harder to appreciate and allow for. However, it's equally important for the people using the app that you allow for this as it is to handle exceptions.
If someone uses an app and when they do something, it causes the app to unexpectedly crash, it's easy to know something is wrong. But what happens when the person does something (click a button, select an option, whatever..) and nothing happens? The thing they wanted or expected doesn't happen, but neither does anything else? Do they try and do the action again? Could that have separate, adverse side effects? Is it being slow? Or slower than usual/previously? Did they do something wrong? Is the app broken?
Creating uncertainty in the minds of the people using your app is not something you want to do. It does not lead to happy users. Unhappy users lead to less usage, fewer sales, fewer recommendations, bad reviews. Nothing good.

As per the documentation, the method returns a boolean value to indicate if the URI could be launched.
Ignoring responses is not always wise and is certainly not a "best practice."

In programming, it's usually good to call a method and trust it will do the thing that's asked of it. However, a function that returns an indication of whether it could do the thing that was asked of it is not to be ignored.
Imagine asking someone if they can do something for you but sticking your fingers in your ears when they say if they can do it or not. You could assume that they can and will do it for you. But, if they say they can't, and you carry on assuming they can (and will), whose fault is it when it doesn't get done?

Do you like ambiguous code? Do you like using software where you can't be sure if it's working as expected? Do the people using your app like software that works like this? If not, don't give it to them.

Connected with the above is the issue of testability.

As the above is a small snippet of a larger codebase, it's not clear how (or if) it is tested. But we can assume it probably isn't.

It might be appropriate to abstract the interaction with the other code to make it possible to easily (and automatically?) test different actions and responses. Such tests can be more important than tests related to your own code, as it's often harder (or impossible) to forcibly get every possible response from other code so it can be tested.

So, what should the above method actually look like?

Well, here I might disappoint you. There is no single "best practice" way to write a version of the above method.

Instead, a "leading practice" would be to handle the response from the method, acknowledge that an exception is possible, and make it possible to test for such scenarios.
Maybe I'll show you an example of such code in the future. Let me know if you want to see it.

The above doesn't only apply to code that is part of the WinUI API.

This applies to any code that you didn't write. It might be an API from the platform, or it could be any library you're using. Any "seam" between code you write and code you didn't needs to be protected.

This doesn't (hopefully-obviously) only apply to WinUI related code, but I found a variation of the above amongst code that was supposed to be an example of "best practices." In lots of ways, it's definitely not a good example but I called this out in relation to WinUI as developers building with it deserve the best help I can give.

Are you still using Visual Studio 2017?

Are you still using Visual Studio 2017?

If so, what for?

Seriously, I want to know.

I ask because support for it officially ends next month! (12th April 2022) but I know that some users of my extensions are still using it.

If you are dependent upon any of my extensions continuing to work on VS2017 now or in the future, please reach out to find out how/if I can support you.

Or just update to VS2022.

For reference, there is more on support lifecycles in this post on the Visual Studio blog.

Don't show this message again - avoid vague options

You've probably seen options like the one above used throughout the software you use.

It might be clickable text like that shown above or as an option with a CheckBox for you to check to indicate an answer you want to always be used in the future.

In theory, this is a good option to have.

As a general rule, you don't want to repeatedly prompt the person using a piece of software to give you the same information over and over again.

Similarly, you don't want to be telling the person using the software the same thing over and over again. They might not need to be told every time and you're likely to annoy or frustrate them if you do.

They might also start(?) ignoring any messages like this and inadvertently miss/ignore something new and important as it looks like something they've seen before.

[Aside: information, warning, and error messages should always be easy to distinguish between. Don't for example, make all of them the same color so the only way to differentiate them is to read the text.]

However, displaying a message like this raises questions for the person using the software.

• What is it that won't be shown again? 
• Is it the exact, specific scenario, or all ones like it? (If the message is about one account/file/project/etc. will selecting this option stop it from being shown again for all accounts/files/projects/etc. or just this one?)
• Does my answer apply to all variations of the displayed message/scenario?
• Does it include displaying the message only in the same circumstances that caused it to be shown? (What if other circumstances or scenarios also warrant showing that message? I might want to see the prompt then.)
• Could the same (or very similar) message be shown for a different scenario?
• What if I want messages or prompts like this to be shown again? (at some point in the future.) How do I (re)enable that?

Yes, I'm someone who can often look at prompts with the "don't show this again option" and think about the possible future scenarios where it might be useful to get that message again. It's often easier for me to just ignore that prompt than try and figure out exactly what selecting the option might do.

When showing such an option, I can see that you're trying to be helpful but now you're adding complications and asking me to make a decision where I don't know the consequences of each answer.

Ideally, the software a person is using should give that person confidence and not raise doubts or questions about the thing you're doing to try and help them. Admittedly, for very large and complicated software that won't always be easy.

I'm not trying to argue that you should never use a prompt like that shown and described above. They can be very useful.

I'm saying that you need to consider the use of these messages and test they are understood by the people using the software. You want your improvements to actually improve things for the people using the software. Adding more prompts and options isn't always the best answer.

Why I wrote (and you should buy) a book about Uno Platform when there are free resources available

The Uno Platform team recently published a list of resources for anyone wanting to learn about the Uno Platform.

Of course, the book I wrote with Marcel is on the list, 

But why pay for a book when there are free alternatives?

The immediate (and obvious) answer is that our book includes information that isn't in the other available resources. There are lots of blog posts, ebooks, and online talks (including some by me) that provide an introduction to the Uno Platform. We intentionally wanted our book to go beyond this. The first chapter is an abridged version of the contents of that other content as that is just the starting point for the real content.

Our book was written for people who wanted to know more than just the basics and build "real" software with Uno Platform.

Want to see how to do some of the things you're likely to do in a typical app? We'll show you.

Are you evaluating Uno Platform as a way to build apps? If so the book will show you how to build more than a "Hello World!" app. This will allow you to make an evaluation based on something closer to what you want to build but without having to do as much work yourself.

The book represents many months of effort. We believe the effort we put into writing the book has financial value. The time you'd take trying to learn and/or figure out the things we show in the book would cost you much more than the cover price of the book. 

The book also isn't for everyone. If all you want is a high-level overview, quick introduction, or a random collection of tips, tricks, and examples of things that are possible the internet has you covered. If it was just about numbers I'd have written a series of blog posts. The daily readership of this blog is higher than the number of copies I expect the book to sell. (Of course, I'd be happy to be wrong about this--and not because of a drop in blog readers 😉) If you want to see how to go beyond the basics and see what's involved in developing more complex app scenarios then the book will be of value to you.

Buy it: Amazon UK or US

Imposter syndrome - a coin with 2 sides?

Lots have been written about Imposter Syndrome, especially with how it relates to the world of software development. I wouldn't normally write about such things here but I've recently been struck by a new, related idea and it felt too long for Twitter.

Talking about complex issues can be hard as it's natural to assume that other people have similar thoughts and experiences as yourself. But that's not always the case.

But what if all imposter syndrome is not the same?

I think there are two kinds (there may be more but two is enough for me, now.)

• I don't deserve to be here.
• I don't deserve to be allowed in there.

The order doesn't matter.

It's easy to think they are the same but there are some subtle differences.

One is about loss and one is about gain.

But, both are about self-doubt, fear, a lack of appreciation for own value, and neither are necessarily rational.

In that "people in tech" often think of themselves as logical and want everything to be logical this can make it difficult to talk about.

It's also possible to have both thoughts about yourself. Not about the same thing but about different or even similar topics at the same time or in quick succession.

It sometimes feels like everybody has imposter syndrome at least some of the time.

Not everything is imposter syndrome though. Sometimes you can be in positions you don't deserve to be in. Sometimes you'd like something, to be, or do something that you're not qualified for or yet capable of.

But what can we take from this? It doesn't sound like I've made any great insight.

Well, here's the thing that struck me. 
It's important not to assume that the imposter syndrome another person is currently feeling the same kind of imposter syndrome as you.

For example:

If you're someone with a job and your imposter syndrome makes you state you don't feel like you should be there, it can be really disheartening for the people who would love to be there but their imposter syndrome tells them that they don't deserve to get a job there. 

Or people with good jobs they clearly deserve saying they have imposter syndrome can be really disheartening for those without a job and have struggled to get one, for years and so feel their own sense of imposter syndrome about being worth employing.

It works the other way too. If you have imposter syndrome about not being recognized or accepted for something, it's tough to hear people who are recognized say they have imposter syndrome about being acknowledged that way.

Beware of dismissing other people's imposter syndrome. Especially when it's different from the type you experience.

Both types of imposter syndrome offer an opportunity for self-improvement. As a prompt to increase technical skills and as an opportunity to acknowledge your own value and worth, regardless of 

Some quick thoughts about writing a first book

A few times in the last couple of months, I've been asked about the writing process from people who are thinking about or planning to write their first technical book.

Here are some of the things that I'm telling those people. I'm putting it here because others might be interested and because it will make it easy for me to find (and refine?) in future, if necessary.

• It's LOTS of hard work. It is very unlikely to earn you much (any?) money. (Especially if you're used to being well paid for your time as a developer.) Are you sure you REALLY want to do it? 
• Be prepared to spend (you should be spending) more time planning and re-writing that writing.
• Interview the publisher. Assess if you want to work with them like you would (should) any employer. Do you get on with these people? Do you want to spend lots of time talking with them? Can you trust them?
• Speak to authors who have worked with the publisher before. Find ones with good and bad experiences. Find out who at the publisher the author worked with. It's the people that matter more than the publisher as a whole.
• Understand why the publisher wants a book on the subject, and why they think you'd be good to write it.
• Technical reviewers are at least as important as the editor. Get lots of feedback from the technical reviewer on your detailed outline for the book. They'll help avoid any big issues not being identified until it's too late (there's not enough time) to fix them.
• Write ALL the code before estimating the wordcount for a chapter. If your book is mostly going to be explaining code or APIs. Yes, this means you have to have a really detailed plan and have done a lot of the work to be able to write the outline and before you sign a contract and start "writing" the book. For reference, I think four lines of text to every one line of code is a good guideline as it's explaining, not just showing the code that's important. You'll also discover that code is actually a lot more lines of code than you imagine in advance.
• Have a backup plan for what to do with your planning work even if you don't finish the book. (A series of blog posts is an obvious answer.)
• Avoid working with a publisher that has very strict structure and expectations for a "type" of book if that's not what you want to write. You probably won't get as much support as you'll want/need and it's harder for them to help you.
• Triple check everything. If it's your name on the cover people will attribute any mistakes or issues to you. (Don't always rely on other people using the change tracking functionality of software or documents correctly.--Guess how I learned this.)
• Ask the publisher for the guidance they give to new authors after they sign the contract, but before you sign a contract. These guidelines often include lots of useful information that will help you write the outline--that will lead to the contract. Consider it a red flag if they won't share it. Speaking of which...
• Trust your gut. I've not (yet) met any authors who had doubts about a publisher at the start but they turned out to be unfounded. I have met many who wish they'd paid more attention to the things the red flags they saw early in the process.

I hope this helps.

XAML is not a Turing-Complete language - but treating it like one can be helpful

What is a "Turing Complete language"?

Good question. You can see Wikipedia for more information, but I think of it this way. It's one capable of taking input and producing output based on some form of logical decision-making or processing. 

Basically, it's a clever-sounding name for a general programming language. (Not to be confused with a general-purpose language with no specific focus and distinguished from languages designed explicitly for a particular problem-space or type of usage.)

I think of it as a shorthand for a language you might use when you could (theoretically) use another language and still get the same result.

So, XAML is not "Turing complete" or a "general purpose" language.

It was never meant to be. It was created to represent a user interface (in whole or part) and, to a lesser extent, as a way of describing (or storing) data. [And this data can also be used to store steps in a process or workflow 😉.]

That you can use XAML in combination with a general (or Turing complete) language is irrelevant. That a compiler may take a XAML file and use it to create a C# (or VB.Net, or F#, or anything else) that is used instead of or in partnership with the written XAML doesn't change the XAML file or how you should think about writing it.

Treating XAML like any other "proper" language can be really helpful.

Taking the attitude of "it's only XAML" or "it's just text" doesn't help. It's an attitude that leads to inconsistencies that can make maintaining the code harder and the introduction of actual bugs more likely. It also makes it less likely that you'll look for tools to help write good XAML and ways of writing XAML code that is easy to read and understand. In turn, this will lead to the potential for more accidental bugs and code that is harder for other developers (including future you) to establish the original intention behind the written code.

As XAML files are part of a shipping application, it's essential to treat them the same way you do any development-related asset.

There are many good practices for working with many (most?) programming languages. Not all of these are relevant to working with XAML, but some are.

More posts on this topic will follow...

Don't give up on XAML yet.

Some people aren't fans of XAML. That's ok.

Some people use it because they have to.

A very small number of people think deeply about XAML. 

I include myself in the third group.

There's a popular trend at the moment to dismiss XAML because of its limitations. 

The argument goes that you should use C# (or equivalent--hello VB fans) to define the whole of the application, rather than use a separate tool (XAML) to define the user interface. This is seen as a way to simplify a codebase and avoid some of the limitations of XAML.

C# is a general-purpose language. You can use it for everything but that doesn't mean you should. XAML, while not a full programming language is designed specifically for defining user interfaces and has appropriate tooling available.

XAML is not a "proper" (Turing-complete) language but it doesn't need to be. It can still do useful and powerful things.

Most of the arguments I'm hearing for just using C# come down to the idea that the tooling for defining UI's in C# should be made better so that people can use that instead of having to use XAML.

I have concerns about this approach:

• It ignores the possibility of improving the XAML experience, which is the ultimate source of the issue.
• It means the need for more work in supporting (developing & maintaining) the ability to create UIs with XAML and C#.
• It indicates that there is no plan, desire, or intention to improve the XAML tooling and experience. Should people, therefore, infer that XAML is in a fixed state and will never be touched again. The consequence of such an idea is that people should stop using XAML. What then for all the existing XAML code that exists? There's an implication that this should probably end up being rewritten in C#. This means that we don't have to jump very far to get from some people being disappointed with XAML to everyone having to rewrite their code so they don't use it.
• It can be harder to visualize a UI from just the C# code. (I recognize that this is just my current opinion though.)
• Separation of concern boundaries are much more easily broken when everything is in one language.
• Just because XAML isn't a "proper" or full (turning-complete) language is not a reason not to use it. Making changes to a general-purpose language (C#) to make it easier to use for a specific scenario seems equally flawed. In fact, when XAML is treated like a "proper" language it becomes much easier to write, read, and maintain that code. (More on this in a future post.)

I will, of course, admit that creating UIs in C# can (& does) make some things easier to read and understand. However, I don't think that should automatically mean we do away with everything that isn't C#. Also, I'm yet to see very complex UIs defined in C# but have seen many complex scenarios implemented in XAML. 

This isn't to say that complex UIs can't be created in C# as well as XAML, it's more to highlight that the situation is complex. It's very easy to reduce this discussion based on personal experiences but the reality is that XAML and C# are used by a very large number of people to build massively varied types of software with vastly differing specifications, requirements, and uses. There are a minuscule number of absolutes that can be relied upon when discussing the options and what's "best" for everyone.

Where we're at now, things are improving for UIs defined in C#.

But, why not also improve them for XAML too?

Yes, XAML has been stagnant for many years and the plans for a XAML Standard ultimately came to very little. 

Rather than complain about the limitations of XAML (& current tooling) instead let's look at how things could be better.

As you might expect I'm doing some tinkering myself with regards to Visual Studio extensions that can be useful, but the XAML-related capabilities are almost entirely without the ability to customize or extend them.

I know it's not reasonable to expect big changes to be made quickly but I don't think it's unreasonable to ask Microsoft to consider improving the tooling that's currently available. So, I'm starting with a very basic suggestion: Add support for compiler directives in XAML. VS/WPF request, WinUI request, .NET MAUI request. (Yes it's sad that there isn't a single place to do this.)

It'd be great to see some more people add thoughts to those proposals. <hint /> 😉

3 reasons I'm learning about CSS

1. To get ideas for things that can be improved in XAML. Seeing some of the cool things that can be done in CSS makes me wish we had equivalents when working with XAML. (No more details here yet, but I have a list of ideas...😉) 
2. So I'm better able to make the switch to "web developer". I know some people effortlessly switch between XAML and web technologies--but that's not me. I, of course, also know that it's possible to create websites using XAML. It's many years since I did any serious web development and I know a lot has changed in that time. I'm also aware that there are a lot more employment opportunities in "regular" web development and I can't live on my savings forever and XAML work is hard to come by. I'm hedging my bets by learning something that may help me now or in the future.
3. So I can learn from smart people. Regardless of the technologies, there is often much that can be learned by watching smart people doing their work and solving problems. Watching how experts in another language think about and solve problems can be insightful and help me think about things in new ways too.

updated Feb 3rd, 2022

Windows Template Studio - reborn!

It was only a few weeks ago that I publicly announced that I'd given up on Microsoft taking the Windows Template Studio forward and so I was going to do it myself.

Now, things are changing again.

• The official Microsoft project has been reborn as just Template Studio. (Yes, that's the name I was going to use too.)
• I'll be bringing the work I've done on my own back to Microsoft's repository and the Windows-related apps that can be generated with it will all come from Microsoft.
• I'll continue contributing as a "community member".
• The extensions I've already released as previews (for UWP, & WPF) will stay as previews and be removed once official Microsoft equivalent versions become available.
• I'm reserving the right to build my own extensions that can be used for things other than Windows apps.
• There's more on the official roadmap.

As expected, the most common question right now is about the timeline.

The answer is that it's likely to take a few more weeks.

This is because:

• I can't take my work "as is" and copy it all over. There are things I can't, don't want to, and shouldn't share from my code.
• What's required in the official repo is different from my personal requirements.
• There's functionality my version has removed that I need to find ways to reinstate for the official/public version.
• There are still [regression] issues in my version (the previews) that I need to fix.

How can you help?

• Try out the preview versions I've released. (There are some things that behave differently in the release builds and so need testing widely--which I can't do in testing.)
• Raise any bugs or issues for things you find. (Are there things I've missed? If no one reports the things that I think are regressions, maybe they don't need fixing...)
• Consider becoming a sponsor. You'll be credited in the previews and elsewhere, but I obviously can't include such images in the official Microsoft version. :(

Any other questions? You know where I am. ;) 

Reasons to ask a question

I've been thinking a lot about communication (I know--fun, right?!) and especially about questions. This is because asking and responding to questions (not just answering them) is a large part of communication.

So, 12(+) reasons to ask a question:

1. To get an answer.
2. To force others to think about the question's topic.
3. To encourage someone to think about how they'd answer (even if they don't.)
4. To get attention. 
5. To get a response (that isn't a direct answer.)
6. To show (admit?) that you don't know (everything.)
7. To show a willingness to learn.
8. To show that asking questions is good/ok/acceptable/encouraged.
9. To show an example of questions that can be asked.
10. To show that you've thought about (or researched) the subject enough to be able to ask smart, informed, appropriate questions.
11. So others can hear the/their answer.
12. Never for no reason. 
13. Other?

I know the above is a generalization, and it won't apply to all scenarios but is a helpful summary of the things to consider.