Friday, July 01, 2022

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

Thursday, June 09, 2022

Plant trees while you search for error descriptions

 Ecosia logo

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.

Screenshot showing the context menu options added by the extension

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!)


Sunday, May 29, 2022

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 


Thursday, May 26, 2022

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]

Partial screen shot of the Visual Studio Installer showing multiple versions installed on the same machine

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



Tuesday, May 17, 2022

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 />


Saturday, May 07, 2022

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>

Thursday, April 14, 2022

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.



Tuesday, March 15, 2022

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!


Sunday, March 13, 2022

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 ;)

Friday, March 11, 2022

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

 

list of installed extensions

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?

GitHub sponsor images



Wednesday, March 09, 2022

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.


Wednesday, March 02, 2022

Are you still using Visual Studio 2017?

Visual Studio 2017 icon/logo

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.


Monday, February 28, 2022

Don't show this message again - avoid vague options

"Don't show this message again" button

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.


Monday, February 21, 2022

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.

Uno Platform - Beginners Guide

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

Sunday, February 20, 2022

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.

"anonymous" mask
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 


Saturday, February 12, 2022

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.

Wednesday, February 09, 2022

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.

Alan Turing - not a picture taken by me but I have seen this statue in person

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...


Thursday, February 03, 2022

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.

some random XAML in an editor

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 /> 😉




Saturday, January 29, 2022

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

Friday, January 28, 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. :(
Sponsor images shown in the wizard

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

Wednesday, January 12, 2022

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.


Thursday, January 06, 2022

Template Studio for WPF

Following on from UWP, I've now released a preview of Template Studio for WPF.

Why WPF? - Because it has a similar position within WinTS as UWP. That is, it is (I suspect) less likely to have a future in WinTS which is likely to (again--I suspect) continue to be increasingly focused on WinUI.

WPF also has an opportunity for a longer life than UWP. Because of this, I plan to extend the provided options and add the ability to create WPF apps that are based on .NET 6.

More importantly, to do this I've got the codebase to a place where it can produce multiple different extensions that build for different platforms and happily work side-by-side. This opens the door for lots of exciting new things going forward. (hint hint)

Anyway, give it a try and let me know any feedback.