I've found a bug in your open source library but I'm not going to raise an issue to log it. Sorry.

I suspect many people think this but never say it. 

It comes down to one simple fact: I haven't got the time.

I know many people will be upset with me for saying this. I also know that I've been disappointed by others who have expressed or displayed this attitude themselves.

So, why aren't I going to report the bug/issue/problem I've found?

These aren't always the case but usually:

• I assume that what I've found is an edge case. (If it wasn't someone else would have logged this previously---I recognize that if everyone thought this nothing would ever get reported.)
• I don't expect it to get fixed. (This is often tied to it being an edge case.)
• I've already spent lots more time on this than I wanted to (can really afford to) so another unplanned task related to this doesn't feel like a good use of my time. 

Expanding on that last point, a good bug report takes time to create. It depends on the project and the issue but for something non-trivial, I've found this can often take me several hours.

If what I've found is trivial to explain and recreate then creating a bug report or issue is simple and I'll always try to create one.

BUT

If it's not simple to explain and recreate, creating a bug will likely be a waste of my time and effort. 

Creating a bug/issue doesn't help me with the project I'm working on. I've just created a workaround that works with the code I have now. 

If the issue is fixed in the project I'll need to spend more time verifying the fix and (possibly) removing the workaround I've had to use.

Having found a workaround that meant spending more time than originally planned, I'll have to spend more time creating a bug (& repro), and then possibly spend even more time verifying a fix and making any necessary changes. Stopping once a workaround is found is often very appealing.

But what about other people who may encounter this issue?

Yes, creating an issue for them to find may help them. If I can share a workaround then even better.

If not an issue, maybe a blog post explaining the workaround would be something faster to create. That way at least there's a document somewhere on the internet for others to find. Sadly, very few scenarios (or projects) warrant (or allow) a brief description of a problem and a workaround.

If my aim is to make the best use of my time to help others, documenting a workaround for an obscure edge case doesn't feel like a good use of my time. Surely there are things I could do that would help more people...

This situation isn't good for anyone.

I don't want it to be like this.

I wish quick, simple bug reports were acceptable. - Even just a brief description that could be expanded upon over time. However, a description without a simple reproduction is likely to get closed rather than left open waiting for more details.

If it was an open-source project, I'd be happy to create an issue that has a description of the problem and a workaround (or link to one if documented elsewhere).

Having detailed instructions on how to report issues including having requirements on creating/including minimal ways to reproduce an issue are appealing from the perspective of a maintainer but are offputting for a person who just wants to use the library/tool and doesn't have the time to create a detailed report. 

Or could there be something better?......

I don't have any answers. 😢

I just wanted to start documenting my thoughts on this subject. I expect to have a follow-up post to this, eventually.

As a project maintainer, I'd rather know about any problem, no matter how vague or seemingly lacking in details. Knowing that something's wrong is preferable to not knowing.

At best it might indicate a gap in the documentation.
At worst it means a vague issue remains open. Possibly indefinitely.

Admittedly, if I had millions of users and loads of vague issues being created I may think differently.

Let me try and be clear (although being very aware the people I've most upset will probably not make it this far before saying something rude about me):

• I want the tools I use to get better, add features, fix bugs, etc.
• If I can and if you make it easy, I will raise issues.
• If you make raising issues hard I'm much less likely to do it.
• I know you're busy and your time is valuable. So is mine.
• If you want to report an issue with one of my open-source projects, I'll happily take as much (or as little) detail as you can provide. The more detail you provide the more likely I am to be able to do something about it. But, I'd rather know there was a problem, even if it can't easily be recreated (yet!)
• I'm aware this approach may not apply to very large projects. (If only this was my problem.)

Thoughts? tweet at me

Are technical computer books supposed to make you laugh out loud?

If you are using the digital version of this book, we advise you to type the code yourself or access the code from the book’s GitHub repository (a link is available in the next section). Doing so will help you avoid any potential errors related to the copying and pasting of code.

Honestly, I laughed out loud when I first read this.

Do you find manually retyping something (already in a digital format) less error-prone than copying and pasting?

Am I unusual in finding copying (& pasting) something being less likely to result in any potential errors than typing it myself?

I get that typing something yourself can help when you're learning something and want to be clear about what code you're adding and why. But, cutting and pasting has always been less error-prone than typing.

Questions to ask BEFORE asking 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(+) questions to ask yourself before asking a question:

1. Can I work out the answer myself?
2. Can I find the answer myself?
3. Will the person I'm asking know the answer?
4. Can they know the answer?
5. Will they be able to give me an answer if they know?
6. What will it cost them to answer?
7. Will this impact my ability or opportunity to ask other questions?
8. Will others want to know the answer?
9. Have others asked the question before? and what, if any, answer did they get?
10. Why isn't the answer easily/already available?
11. Is this the best time to ask? And if not, when is?
12. Have I been paying attention to what has been said already?
13. Other?

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

Not all are always relevant, appropriate, or useful, but all are worth considering before asking (or even answering) a question.

Questions to ask BEFORE answering 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(+) questions to ask yourself before responding when asked a question:

1. Do I know the answer?
2. Can I tell them the answer? (If I know.)
3. Should I tell them the answer?
4. Why do they want to know?
5. What assumptions do they have that have led to (or are evident from) the question?
6. Why do they think I know (or can get) the answer?
7. What will they do with the answer I give them?
8. Is there something I can give them better than the answer to their question?
9. What led them to ask this question?
10. Are other people likely to have this question?
11. Where else can I share this answer?
12. What type of answer are they expecting? (long, short, etc..)
13.  Other?

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

Not all are always relevant, appropriate, or useful, but all are worth considering before answering a question.

Forking Windows Template Studio

Windows Template Studio is a Visual Studio extension that helps developers scaffold Windows applications. 

I have a long, complicated relationship with the project and have been involved since its inception.

In June, Microsoft stopped funding the internal team who were working on it. I was told there were plans to continue the project with support from the community, but this didn't happen, and my emails have gone unanswered since then. 😢

Sadly, due to the way the project is set up and configured and because of the permissions I have, it's impossible to do anything significant within the existing repo.

So I'm taking it upon myself to do something separately.

Announcing Template Studio for UWP. (preview for VS2022 available now!)

Yes, it looks very similar to the Windows Template Studio wizard.

I'm starting by taking the UWP (and then WPF) capabilities of WinTS and breaking them into separate extensions that work with Visual Studio 2022.

WinUI(3) support will hopefully follow. As will support for creating apps that don't only run on Windows.

There's lots of detail I'll spare you from, but the bits most likely to be of interest are:

- My goal is to help developers now. (When Microsoft has left them in a state of uncertainty.)

- I'm updating the dependencies in the generated apps and will add other improvements and new functionality.

- I want to reduce the dependencies on developers installing the extension(s). You shouldn't need the capability to build any/every type of Windows app just to use the extension.

- I'm starting by focusing on the parts of WinTS that are less likely to be supported by Microsoft (UWP & WPF) if they do resume development (& support) of WinTS.

I'm open to contributing to the WinTS project again, but I'm not just sitting around while I wait.

- I'm doing this in a way that gives me the best opportunity to do other things with the code in the future. (Look at me being all mysterious. 😉)

- I'm taking the opportunity to make some much-needed (in my opinion) updates to the project and its internal dependencies. 

- It's not open source (yet), but I'm not ruling it out for the future. (I have many reasons that I'll save for another day/time/place.)

It's in preview now & I'd love feedback.

I'm updating (most of) my Visual Studio extensions to support VS022

Visual Studio 2022 has a lot of changes and new features.

The biggest one for me is that most extensions that supported earlier versions are not 100% compatible with this new version.

This means creating a new version of each extension that I want to be available on both VS2019 and VS2022.

Due to the way that I'm creating new versions (I have my reasons), it's possible that you can install two different versions on VS2019.

If you have multiple versions of an extension installed, you should uninstall the one that doesn't have "(2019)" at the end. If you're only using VS2022 then you won't see this.

For the most part, having both installed shouldn't be a problem but it might lead to some duplication of output or other strange behavior. I recommend you delete the older version. 

I haven't yet made VS2022 versions of all the extensions available yet. For the ones I haven't done yet, I have a (private) list for the order in which I will change them. Ones with more requests (especially from my GitHub sponsors) get top priority. Not all will be made available on VS2022 and some will take longer to do due to the complexities of migrating the code. If there's something you're curious about (want sooner), open an issue on the appropriate GitHub repository or send me a message.

I'm also using the process of reviewing and updating these extensions to add a prompt to try and encourage more of you to become a sponsor. Sponsor me any amount, either as a one-off on a recurring basis and I'll tell you how to make sure you never see this prompt again. Other sponsor benefits are planned for the future too. ;)

If you're curious, I might share how effective this is, but early feedback has been positive.

UnoConf (2021) - Quick reactions

UnoConf happened earlier this week.

If you missed it, you can watch it online.

There were some big announcements, including the launch of version 4.0. You can learn more from the video or read more in their official blog.

Rather than repeat what you can read elsewhere, I thought I'd share my initial reactions:

• As with UnoConf announcements in past years, it's impressive how much new functionality and how many new features have been added.
• It's exciting to see a push beyond just porting existing UWP/WinUI controls and adding new controls (as part of their new toolkit.) [Some of these look like they make some of the steps in the book redundant--and I'd like to find the time to investigate this.]
• It's exciting to see the Uno Platform team do things that push the wider ecosystem forward and provide broader functionality that Microsoft hasn't created yet. (Even though many assume that Microsoft should have.)
• It's also exciting that the team is trying to improve the way developers work by introducing their own framework. Hopefully, this will enable some developers to work more effectively and not confuse things. It'll be interesting to see how the message of "you can do and use everything you do on Windows and have it run everywhere" balances with a message that suggests "Uno Platform has their own way of writing code."
• It was sad to see the continued lack of clarity about the terms UWP, WinUI, & WindowsAppSDK. I know this is a problem caused by Microsoft and not the Uno Platform team. Still, by saying they're using WindowsAppSDK 1.0 and .NET 6, someone could easily be confused that they're still using UWP to build the Windows version of apps and have not yet switched to using WinUI3 (because they can't.)
• I also got the impression that there's a stronger push to encourage people to see the Uno Platform as an option when just building for the web. If this becomes a popular solution, it will definitely be good for the growth and adoption of the platform as web development is such a big market.
• While it's clear that adoption and usage are growing, there is still a lack of large apps that have been shipped (and can be talked about publicly as examples of what's possible). That the customer demos and testimonials from the event showed apps in progress or that are shortly to be released didn't help address this concern. Better than showing no customers, though.
• That 3rd party control vendors used the conference to (re?)confirm their commitment to the platform was also good. But, I got the impression they're waiting to see more platform usage (& their controls) before committing more heavily.

All in all, very positive, although there are a few things I'm cautious about. 

I'm keen to try some of this out and hear the broader feedback once more people have started using v4.0.

What are your thoughts from the conference?

How to respond to 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, 9(+) ways to respond when asked a question:

1. Ignore the question. (& the person asking?)
2. Refuse to answer.
3. Admit that you don't know.
4. Admit that you can't answer. (yet?)
5. Use the fact that the asker has now stopped talking and take the opportunity to talk about what you want to.
6. Pick a word from the question and talk about that. (Because not properly listening, or as a way to avoid answering the question directly.)
7. Talk about a topic related to the question. (Because that's what you want to talk about, or as a way of avoiding the actual question.) 
8. Directly answer the question.
9. Provide information/suggestions/ideas related to the question that will allow the asker to find (or decide) the answer themselves.
10. Other?

I know the above is a generalization, and it won't apply to all questions but is a helpful summary of the options that are generally available.

 Not all are always possible, appropriate, or useful, but all are worth considering before asking (or even answering) a question.

I learned a shocking secret about many technical books

One of the reasons I wrote a book about the Uno Platform with a new publisher was to learn more about the book publishing process so I can look to self-publish in the future. One of the things I learned shocked me.

This fact is that, apparently, many authors don't check that the source code that they include in their books actually works! Additionally, many editors and publishers don't check that the source code that they include in their books actually works either!

I didn't want to be like this.

As part of my process for testing and verifying that everything a chapter was complete, I'd work through the contents of a chapter, following each step and making sure that it included everything exactly as it should be. This would mean starting with a new project, following each step as written, and copying (cutting and pasting) the code into the editor as I went.

For each chapter I wrote in the Uno book, I did this whole process at least three times. Not wanting to rely on assumptions or trust that what I thought I'd written, or knew what to do matched what was in the manuscript. I'd repeat the process after each round of reviews and when I made big changes to the order of steps or the code so that everything still worked as intended.

For the final round of my testing, I thought it might be an interesting artifact to record the process and so I did. Below are videos for the chapters I wrote showing how I went through each chapter to check all the instructions (& code) worked. Sorry, the sound isn't great but hopefully it's good enough if you really need to hear it.

Chapter 4 - https://youtu.be/OTr1yT_4W_g

Chapter 6 - https://www.youtube.com/watch?v=CIpMcKmTehA

Chapter 8 - https://www.youtube.com/watch?v=oGyMGEut5Zw

Any questions about these chapters (or the book in general) I'm sure you can work out how to get in touch ;) 

Creating Cross-platform C# Applications with Uno Platform

That sounds like a good name for a book. Doesn't it? ;)

And it is.

I know that when I finished my first book I made a specific point of calling it "my book and not my first book."

Save your judgment.

Like most writers, after finishing my first book, I wasn't in a hurry to ever write anything again.

But things, and times, change.

While I wasn't in a hurry to write another book I was still using writing as a way to communicate and pass on information.

Last year, I realized there were specific things I didn't know about the writing process and set out to understand them better. I wanted to learn so I could be a better writer and communicate more effectively. So, I spent much of the first pandemic lockdown reading books about writing, watching videos about writing, listening to podcasts about writing, and attending online workshops about writing.

Fast forward to earlier this year, and I was approached about writing a book about Uno Platform.

I wasn't in a position to write a whole book but the publisher called my bluff and agreed to me becoming a contributor to one. I figured I could write four chapters of a book and learn more about the process that would help me with my own future self-publishing plans. (More details of these at another time.) It would also be a way to test if I could apply what I'd been learning.

When it suits me, I can be quite assertive and I had strong ideas about what this book should and shouldn't be. I was keen that if I was writing the book, it would be distinctive. There's no point in me doing what just anyone could do. I wanted to make this my own. (Well the chapters I was writing, at least.)

When it comes to technical books there is a convention that over the course of the book the reader will build a basic app and each chapter will add to it as a way to learn about and demonstrate, a new feature or area of functionality. I didn't want to do this and my reasoning is threefold:

1. I didn't want it to be like every other book. 
2. I'm not a fan of this convention as it tends to strong-arm features into an app in an unnatural way. I knew trying to do something I'm not a fan of would be frustrating and as writing a book is already a slow, hard, frustrating process this wouldn't be good for my sanity or motivation.
   (I mean no offense to people who write such books. I have great respect for you as you're doing something I can't.)
3. Most importantly, it didn't fit the subject. 
   Uno Platform enables the creation of an app that can be compiled for multiple platforms but the number of cases where it is appropriate to have the same app run on all those platforms is very small. Instead, I thought it more appropriate to show how Uno Platform can be used to create apps for a number of different scenarios that demonstrated appropriate features running on appropriate devices/platforms.

So, instead of a book that walks you through building one app over the course of many chapters, this book shows how to create multiple apps, one per chapter. The goal is to show how Uno Platform could be used within an organization that needs to build lots of different kinds of apps (both internal and public-facing.) My hope is that when you see the organization we use, and the variety of the apps of apps we create there will be something you can relate to and is comparable with the apps you are considering building.

The book attempts to answer the question "Can I use Uno Platform to build the apps I need to?"

Obviously, there's some theory and an explanation of when and why you would use Uno Platform, but my hope is that by showing how Uno Platform can be used to build some very different apps, that run on different devices (mobile, desktop, and web) you'll see where and how you could be using Uno Platform too.

Is this ambitious for a short, introductory book?

Will I learn that all those other books only build one simple app because it's better for the reader than building many apps?

Will everyone involved have the same vision for the book as me?

Possibly.

You'll have to buy it to find out.

Pre-order from Amazon

What should you do with your UWP app?

Originally, the expectation was that WinUI3  would have support for both "Desktop" and "UWP" app models.

The focus was initially on Desktop with the promise that UWP would follow. Now, it's looking more and more likely that UWP might never be fully supported by WinUI3.

I can see this as a realistic scenario. The intention might be that one-day UWP support is added but it looks like it's very low priority and there are a lot of other things in front of it.

So, what if you have a UWP app?

If your app is only used on a desktop/PC then consider converting it to WinUI. Probably wait for WinAppSDK v1.0 and check that everything you need is possible in WinUI3 but that's your future.

If your UWP app is for use on desktop/PC and Xbox then you'll need to stick with UWP while we wait on future announcements.

If you're still hoping for a return of Windows Phone, then I can't help you.

Or, you could just keep it as it is. It should be good for a few more years at least.

A cynical take on today's Windows announcement

A cynical response is all I can manage today.

Plus, my cynical view of past events has been appreciated by some and found entertaining to others.

Let me give you the highlights and answer some questions...

---

Do you remember how Windows 10 was going to be the last version of Windows?

....

Introducing Windows 11

Eventually. It seems that in an online event about the future of Windows, they're using streaming tech from ten years ago.

(and also, this)

Do you remember how Windows 8 changed the start menu and how people complained and then, in response, Microsoft put it back where and how it was?

It's moved.

And looks different.

Anyone taking bets on how long before there's an app in the store that mimics the old start menu?

--- 

"Hey Matt, as you're a Windows Development MVP. What can you tell us about developing for Windows 11?"

Only what was in the announcement. I had no advanced knowledge of today's announcements. I only knew it was coming from the "leaks" on Twitter. There is also an official blog post announcement for developers.

"There seems to be a lack of major changes. It looks a lot like an update to Windows 10 but with an extensive UI refresh."

- Yes, it does. Doesn't it. Hopefully, we'll see the bigger differences in time.

"There seems to be a big focus on PC gaming."

- Yes, there does. People use PCs for gaming. A lot!

"Is this why there haven't been any big updates for Windows in the last few years?"

- Probably. Of course, it's complicated, and there can't be big changes every few months, but this could be connected by the fact I can't remember any noteworthy updates for Windows 10 within the last 2 years.

"There was a lot of focus in an updated UI. Will all apps from Microsoft be updated and look like this?"

- You can probably expect most of Office to look like this and many of the apps that come with Windows to be updated, but there will be some that aren't updated and will keep the look they've had for years (forever!)
From a development perspective, I'm curious what happens with the controls in WPF & WinForms apps.

"Will everything go (back?) to having rounded corners?"

- The trend for rounded and square corners alternates. Don't worry if you're not a fan. It'll change again in a few years.

"A lot was made of the 'sheet of glass' look in the video. This looks like what was called 'Acrylic' previously. Is it the same thing?"

- Very similar. There's more about Mica in the docs.
Again, with my developer hat on, I'm aware of issues relating to using and implementing Acrylic for WinUI3. So let's see where, when, and how this is available to developers...

"I'm curious about how the new design is meant to help 'bring a sense to calm.' What about all the slow, buggy apps and poor UX experiences that frustrate me? Are these getting fixed as well? Or is the new design merely a distraction from poor UX?"

- Let's hope that work is being done to help with the poor UX of many apps. I don't think an OS update will magically fix anything in this area, though. BTW. If you're interested in improving the UX of your app, I wrote a book that can help you.

"Some of the new features look like updated versions of things that were already available in PowerToys. What's up with that?"

- One of the goals of Power Toys is to try things out that may eventually end up "in the box." This is an example of the learning from Power Toys making it into the OS. It's not the same, and I don't expect to give up using Fancy Zones even when using Windows 11.

"A lot of the announced productivity features are things that we've been asking for for years or are things that already exist (such as vertical tabs in Edge) are they worth making a big deal about?"

- Time will tell when we've had a chance to use them for a while. Hopefully, lots of little improvements will lead to a big overall improvement.

"If Teams is integrated into Windows, does this mean they've fixed all those annoying inconsistencies, bugs, and issues with switching between tenants?"

- Let's hope so....

"Windows widgets seem a lot like updated versions of live tiles from Windows Phone and Windows 8?"

- That's definitely a reasonable comparison.

"The page for getting more information (https://www.microsoft.com/en-us/windows/windows-11) includes a tool that can be downloaded to check for device compatibility, but it's packaged as an MSI, rather than an MSIX. I thought MSIX was the recommended format for installing apps. Why isn't this being used? Is MSIX supported for Windows 11?"

- Expect MSIX to continue to work on Windows 11. MSI still works. I assume that it wasn't used here to enable support on devices running ancient versions of Windows that don't support MSIX. 

"What can you say about the game pass?"

- Nothing. Games aren't really my thing. (I might be getting old and boring...)

"What's with the new store? This seems to get a refresh every few years, but people don't like using it, and it seems to regularly give unhelpful error messages."
- The store has been rewritten, and hopefully, this will address many of the issues. More here

"Android apps running on Windows!!! What's that about? Wasn't it tried before?"

- Yes, this was tried before. Hopefully, the new "Intel Bridge" will work better than past efforts, as it emulates ARM instructions on Intel processors. Expect there to be limits on what those apps can do when running on Windows, though. Not that there will be things that don't work (there may be a few edge cases) but don't expect them to use all the native features of Windows when they were built for Android.
This is based on the "Windows Subsystem for Android." (Yes, similar to and related to the Windows Subsystem for Linux)

"What else is coming for Windows app developers?"

- A few things:

1. With the new store, you can use whatever you want to handle commerce, and Microsoft won't take a cut if you use a separate payment solution.
2. An update to PWABuilder.
3. A reinforcement of the intention that you should consider WinUI3 as the framework of choice for building native Windows apps.

"Any updates related to WinUI3?"

- Not really. Version 0.8 is now officially released. But most of the work that has been done since the last release (v0.5) has been experimental work in preparation for the 1.0 release.

"What's the 'Windows Apps SDK'?"

- That's the official name for what was previously known as "Project Reunion." 
(Yes, it's a long wait for an uninspiring name. I wonder what else was considered and rejected...)

"Apparently, 'Windows is more Open' now, does that mean Open Source?"

- Nope, I don't expect Windows to ever be fully open source, but some technologies and parts of it are, and more are expected in the future.

All this is very new. I make no guarantees about the above and expect to share more information in the future.

I don't think you should only test manually

In response to my post When it's Ok to break the build some people thought I was trying to argue against using CI/CD tooling to test changes.

This isn't the case.

Only running tests manually and/or on your main development machine can be slow and a waste of resources.

Creating a draft PR to test against a large test suite and only raise to a full PR when everything has been confirmed as being ok is a good way of working.

Pushing local changes to a private branch with a CI/CD process running tests against it can be a good way of working.

Either of the above is also a good way of incorporating the execution of extensive test suites or tests that involve multiple environments or varied configurations that would be impractical to set up or maintain on each developer's machine.

My objections and concerns come when a full (non-draft) PR is raised before tests have been run.

BTW. I'm currently planning a book all about testing. It will focus more on the concepts than the details, but I think I can bring some new ideas to the subject. (Hopefully, I'll do a better job at avoiding confusion than I did in that other post.) If you want to know more, be sure to sign up for my (very occasional) newsletter. 

When it's Ok to break the build

For some teams, and some developers, breaking the build is a terrible thing that should be avoided at all costs. (Not just because you may have to buy everyone donuts if you do.)

I used to be fine with anyone breaking the build (and not just because I like donuts.)

This came with some qualifications:

• You shouldn't do it deliberately.
• You should be making small, frequent changes that are less likely to break anything.
• You should fix the build ASAP if you do. (You don't go home having broken the build as you'll be blocking other people.)

But, all in all, I'd not sweat it if someone broke the build. I'd rather they were doing that because they were shipping code and not sitting on massive changes or holding back because they were worried about breaking it.

For the most part, this approach has worked well for many years.

But recently, I've encountered behavior that's making me reconsider this idea.

The behavior I've seen is developers using the CI process as a way to validate their code.

I've seen attitudes like:

"If it fails, I'll find out when the CI process tries to build it as part of the PR automation."

"I won't bother running the tests myself as the CI process will do it for me."

"If the CI process fails, it will create a new issue, and if I fix that, it looks like I'm closing more issues."

These thoughts scare me:

• They indicate a lack of professionalism and pride in the work being done.
  (Why wouldn't you check that it works before saying you're finished?)
  
  
• They indicate a lack of respect for the value of testing.
  (Why wouldn't you check that there are no unintended consequences of the changes you've made by running the tests? - Ok, It may take a while, but surely it's better to be safe than sorry. If running them takes a long time, isn't it better to know about problems sooner? And especially to know about them before you get engrossed in whatever the next thing is.)
  
  
• They suggest you can work the system to look more valuable and productive, and presumably, the organization rewards this.
  (This sounds like you've found a way to make your life simpler at a cost to the product, the company, and the team/your peers. That doesn't sound healthy. It sounds like your manipulating the data to appear to be closing more bugs when actually you're the cause of many of them.)

Don't be like that.
Make an effort to ensure that your code works, doesn't break anything else or have unintended side effects, and that you're helping your team to all be as productive as possible.

So, when is it ok to break the build?

If it's an accident that you attempted to avoid, and will fix it quickly.

When is it not Ok to break the build?

There are many reasons, but my current bug-bear is that it's not ok to break the build if you do it because of laziness.

Is this TDD? (When you can't do: Red-Green-Refactor)

I've been thinking a lot about testing recently.

Specifically, I've been thinking about using TDD and legacy code. (Yes, I've got Michael Feathers's book and will need to reread it. This is probably covered there.)

So, I've just received a bug report that I decide to work on and fix:

1. I created some tests that recreate the issue. Running them verified that they reproduced the issue (they failed) so my tests were RED.
2. I then changed the code so the tests passed. Now my tests were all GREEN.
3. Then I tidied up the code a bit more. (I REFACTORED the code.)
4. Finally, I ran the tests again to make sure they all still pass. They did.
   
   
5. But then I thought of another edge case that wasn't currently tested but probably should be.
6. So, I create a test. And, it passes!

Oh, no! It didn't go Red first, so I can't be doing "proper TDD"™.

I'm happy that the code does correctly handle (and document) this test case but how should I test it "properly"?

• Change the code so the test fails? and then change it back?
• Change the test so it fails? and then change it back?
• Just leave it?
• Something else?

What would you do?

BTW. I'm currently planning a book all about testing. It will focus more on the concepts than the details but I think I can bring some new ideas to the subject. (Despite what you may think by me asking this question.) If you want to know more, be sure to sign up for my (very occasional) newsletter. 

Free t-shirts for XAML developers

 Today I got to celebrate the Rapid XAML Toolkit officially reaching 1500 installs. 

(It has more users than this but that discussion can be for another day.)

I was also reminded I still have this box of t-shirts under my desk since the start of last year and obviously haven't been able to give them away at the conferences I was originally planning to.

So, let's have a give-away.

I have t-shirts and a desire to improve and promote my tools.

You have an interest in obtaining a t-shirt and ideas that may help me improve the tool.

How's about this:

To enter the draw for a t-shirt:

• Download and install the extension.
• Create an issue on GitHub that is either a Feature Request, a Bug Report (if you find a real bug), or Usage Feedback. 
• At the end of your issue include "#tshirt"

Then on June 10th 2021, I'll randomly pick some people who've created issues and send them t-shirts.

Obviously, the goal here is for me to gain some useful new feature requests or suggestions. I'm also interested in how people are using the toolkit and so if you don't have any ideas for new features it's also useful for me to know how it's being used (telemetry is deliberately very limited) so please share what you've done with it or how it's helped.

I couldn't possibly say if leaving a positive (5⭐) review in the marketplace will help your chances of winning, but it definitely won't hurt ;)

Conditions:

1. This is for fun and to help me tidy my "office"
2. Any created issues that don't contain useful (as I determine it) details will be excluded from the draw.
3. The number of winners will depend on the number of entries and the number of t-shirts I have (I don't know right now) 
4. Maximum of one prize per person but feel free to make multiple feature requests.
5. The selection of winners will be as "random" as I can easily manage.
6. Winners will be notified once and will have a limited amount of time to claim their prize. (I'm not going to chase winners indefinitely.)
7. I'll pay postage. Import duty, taxes, or anything once I've posted it are on you.
8. Don't like how this giveaway is being run? Tough.
9. If this is successful I may do this again. No promises.

Rapid XAML Toolkit v0.12 - Now with extra Xamarin.Forms related goodness

After a longer than desired period of time, version 0.12 of the Rapid XAML Toolkit is now available.

If you're not familiar, the Rapid XAML Toolkit is my side-project that's grown out of control. It provides a number of tools to help developers working with XAML files inside Visual Studio.

In addition to a load of bug fixes, this version adds more functionality for working with the XAML files of a Xamarin.Forms project.

The image below shows examples of some of the things that it can now identify inside the editor.

In the screenshot above you'll see that it highlights a number of different issues as either suggestions, warnings, or errors. Wherever possible it includes automatic fixes or will point you to more information about why the issue has been highlighted. Like Roslyn Analyzers in C#, you can also selectively disable or change the error levels of each issue too.

Join the more than 1500 people who use it every day - INSTALL it now!

Why v0.12? Why not v1.0 yet?

I'm trying to balance functionality and expectation.

It's not a preview but it doesn't yet have everything that I want it to. Once it includes examples of all the areas that will show its full potential, I'll upgrade it to version 1.0.

Getting started in "app" development - what do you need to know from a conference session?

Recently, I've been critical of conference sessions that say they are focused on "app" development without saying what type of app they mean.

If someone only works with "mobile apps," that's what they assume when they hear "app."
If someone only works with "web apps," that's what they assume when they hear "app."
If someone only works with "desktop apps," that's what they assume when they hear "app."
And so on for other types of "app."

I first encountered this many years ago when I had a version of the following conversation:

Me - I build apps.

Them - You mean web apps?

Me - No, mobile apps?

There are now so many kinds of "apps" that on its own, the word "app" doesn't mean anything. Or rather, it could mean one of many things. It needs clarification.

Going back to conferences. In the past, I've attended sessions that I thought were going to be about one type of app that turned out to be another. I know many others have done the same, and they have been rightly vocal about the misrepresentation of what the session would be about. This ambiguity doesn't benefit anyone and can end up wasting the time of lots of people.

This year I've encountered a new, related idea. A conference session for people building any kind of app and with any level of experience to share their knowledge so attendees can learn from each other.

I'm a big fan of developers learning from (and with) each other, but this type of session raises lots of questions and concerns for me.

On paper, this seems like a good idea from an organizer's perspective. It can be seen to empower attendees, it has the potential to give people the information they're after, and it doesn't involve a lot of preparation.

Sounds good in principle, but what about the attendees?

Who's going to come?
I think there are three groups of people who might come.

1. Those wanting general, broad information. For these people, they may learn something useful.
2. Those coming with specific interests and questions. These people may or may not get what they want (or expect) and have a large potential for being disappointed.
3. Those wanting to come and share their knowledge (most probably in a specific area.) These people may need careful (skilled) moderation to stop it from being a session driven by them. Plus, how do you balance what the more experienced attendees want to talk about or share and what the less experienced attendees want to learn? These may match up, but it risks being a waste of everyone's time if they don't. The broader the number of types of "app" being included, the greater the chance of a mismatch of reality and expectations.

So, lots of opportunities for it to go wrong, but could a better alternative exist?

What would a good/useful session for ANY app developer look like?

Let's start by thinking about what makes someone an "app developer". There are many different kinds of developers but for simplicity, let's divide them into two categories: those that build software with a UI, and those that don't.

Of course, there are edge cases and exceptions, but  I think it's broadly true to say that any software with a UI could be considered an app.

Now we have an idea of what an app is, there's a key factor that we must remember. For the most part, only a small part of any software with a UI is comprised of the UI. Most of the code and development effort goes into things that aren't the UI.

Yes, the UI is important and may be created from multiple technologies, but these are only a small part of the overall app and what a developer needs to know.

In terms of the broad topics that an app developer needs to know, these are the same as what any developer needs to know.

These include:

• The languages, tools, and frameworks they'll use.
• Structuring/architecting a codebase.
• Testing.
• Good development practices. (however you define them)
• Understanding the user
• Understanding the business
• How to work as part of a team
• Support, maintenance, and updating software.
• Packaging and distributing software. (Yes, even non-apps need this.)
• and many more...

These are all massive topics, and there's no way to get into any level of useful depth in any of them (let alone all of them) in a single session.

This is all to suppose a conference session covering all the things a developer needs to know is a useful and a good use of attendee's time. It's little more than "here's a list of things you need to know."  Is this a good use of 30-60 minutes as part of a large conference? I don't think so. It sounds like an outline of a curriculum that could take months or even years to cover.

Now, I've never run a massive conference with thousands of attendees. I don't know what the goals and aims of the different sessions are. I just hope there are some excellent reasons for including a general-purpose session that gets lots of different developers with different experience levels in different technologies together to talk. I just don't know what they could be.

The goals and desires of the organizers and attendees must always be considered when planning sessions.

I have organized and spoken at many (>100) smaller events and have recently been thinking a lot about what these will look like once the pandemic is over. Seeing the above-mentioned session has seemingly touched a nerve with me, and I wanted to write something to help process my thoughts. More of my thinking will likely follow...

Here, I made a way to navigate between ANY files in Visual Studio

Being able to navigate between different parts of code is really useful. You simply hold down the ctrl key and click on an item, and you're taken to the definition of a method, or class, or whatever. Or, maybe you use a shortcut or context-menu entry to do the same. However you do it, it makes navigating a codebase much easier and saves untold time.

But what if you want to navigate between files that aren't all code, or in the same programming language?

Visual Studio doesn't support this, but don't worry, I can help. 

Introducing CommentLinks, a Visual Studio extension to enable links between any files from within the Visual Studio code editor.

The idea is simple. In your code, you put "link:" followed by a filename, and then a button (see below) is added that, when clicked, will take you to that file.

It will search for files anywhere in the solution. The file doesn't have to be in the same directory, project, or in any project. It just needs to be visible in the Solution Explorer.

If there are multiple files in the solution with the same name, you can specify the one to find by including the directory name(s) to be clearly unique. e.g.:

link:otherjs\device.js

or

link:otherjs/device.js (either directory separator)

Want more than simply opening a file?

You can open the file at a specific line by adding "#Lnn" (where nn is the line number) after the file name. e.g.:

Link:plainfile.txt#L33

You can open a file and search for specific text by including it after a colon (:) immediately after the filename. Or after "#:~:text=" to match the convention for text fragment anchors.

link:device.js#:~:text=Device.prototype.getInfo

link:device.js:addConstructor

And, it can handle spaces in the search text or filename by using percent-encoding (so a space character is replaced with "%20") or by putting them in quotes (single or double.) e.g.:

link:device.js:"getInfo = function ("

link:"device.js:getInfo = function ("

link:"name with spaces.js"
link:misc%20files/other%20device.js

You can navigate within the same file (to search for subsequent occurrences of text) by specifying the file's name and then the search text.

You can open any file on disk by specifying the full path. e.g.:

link:C:\Temp\TestFile.txt

You can even use it to run arbitrary commands by adding "run>" after "link:" This can be useful to open other applications, open files in their default application, or to run commands with custom schemes/protocols. e.g.:

link:run>cmd.exe

link:run>mockup.pdf  (assuming in the same directory)

link:run>ms-settings:easeofaccess-highcontrast

Don't want to use "link:" before the file name?

That's ok. You can change this to any text you want by going to Tools > Options > CommentLinks and changing the Trigger word.

The name might be misleading. It doesn't just work with comments but anywhere in the code file. The name came from the original intention and the fact it was expected only to be used in comments. It works anywhere.

Get it from the marketplace and let me know what you think.

Want to see it in action? See this quick video I made previously showing some of the features.

This is part of a collection of Visual Studio extensions I have made. You can see them all at https://marketplace.visualstudio.com/publishers/MattLaceyLtd 

I originally created this at the suggestion of one of my GitHub sponsors. Not only am I really grateful to the people who sponsor me (the current ones and those who have sponsored me for a period of time in the past, but I also try and do things to help them.

I can't always build everything my sponsors want or need, but I'm inclined to help them more. 😉

This was built for a specific niche use-case, but other people have already found this extension and requested many of the features it has. It turns out that working with multiple file types in VS isn't something that everyone needs to do, but the people who have to do this are very disappointed with what comes in the box and are keen to see additional capabilities added.

One such person who wanted a new capability even paid for this to be added. They wanted a feature I wasn't sure about adding. I was going to suggest to them that this was the sort of thing I'd be more inclined to do for a sponsor, but before I could email them, they'd sent me some money. Not a lot but not a trivial amount. That feature was added quickly ;)

I'm still not entirely sure how I feel about someone giving me some money and then asking for a feature. Still, I didn't want to discourage someone enthusiastic about the project. I especially didn't want to discourage anyone willing to give money to an open-source project.

Based on the time required to implement and support the feature, it's less than I would charge for regular work at an hourly rate, but it was certainly appreciated.

When everyone's working together for the collective good

"Why do you care? You're leaving at the end of the week."

I've been reading, the excellent, Turn the Ship Around by L. David Marquet.

It's made me reflect on two work-related scenarios:

The first is where the above quote comes from. It was after the weekly developer-team meeting and two days before I left the company. In the meeting, I advocated for a change to a process that I thought would improve the time and effort required. I wouldn't be around to see the benefit, but everyone else would. That a colleague asked me why I cared when I'd be leaving confirmed that I wasn't a good fit for the company I was soon to leave. I wonder how many people in this world are like this colleague. I hope it's only a few. I fear it's a majority.

The second scenario is more current. I'm being passively-aggressively encouraged to step away from an open-source project I've been contributing to for several years. A change of leadership and priorities (that are no longer public) clash with my desire to understand why decisions are being made and being open about what is happening in an open-source project. Not wanting to stay where I'm not wanted, I'm thinking about where to best focus my time and attention next. But I'm also concerned about what I'm leaving behind. Before I go, I want to ensure I'm leaving it in the best possible state, and that means continuing to strive for improvements. I'm still trying to work out how to do this in the best possible way and am open to suggestions.

I want to make things better. In addition to the products I work on, I desire to make the places I work, the projects I work on, and the processes I use to make things better.

Is this misguided? I hope not.

Is this all a case of me caring too much? If so, how much is too much?

What's it like when everyone on the team is working to make not just a great product but improve the process as well? - If you have experience of this, I'd love to hear about it.

Is your organization looking for an experienced .NET & Windows developer who isn't afraid to speak up and improve processes?  I might be a good fit. I'd love to hear from you too. 😉

Open-source is like politics - show up to make a difference

Open source is like politics.
But, probably not in the way you're thinking. Not politics in a negative sense as if it's all about power, domination, and control.

Photo by Element5 Digital on Unsplash

I think open source is like politics in that many people think about it in the same way as they do the politics of local government.

What do these refer to?

• Generally, people think it's a good idea.
• Typically, people take what they can from it and don't give back beyond what's required/forced.
• People think about getting involved a lot more than they do.
• Lots of people have [strong] opinions but don't act on them.
• A few people contribute a lot (of time and effort).
• People who contribute are rarely rewarded or compensated well.
• When a person is directly affected, they may show up wanting action on the issue that affects them. But, their desire to look at (or consider) anything else is small, and their enthusiasm is short-lived.

Were those comments about local government or open-source software?

I hope you can see they apply to both.

I think the similarity also extends to how to make a difference in each.

Who are the people who make a difference in local politics?

They're the people who turn up. Repeatedly, regularly, and when it's not always in their immediate interest. They do things to help the community.

Four things to do:

1. Show commitment. Turn up regularly. (Not just to be seen but also because it's often the only way of knowing what's going on.)
2. Work for everyone's benefit. Do things that help others, not just you.
3. Share your knowledge. Not to show off but to help others.
4. Think long term. Not only immediate benefits.

Doing the above will build trust and a reputation that will support your big ideas down the line.

Yes, large organizations and people with a lot of money, influence, or celebrity can come in and make a big difference in a short amount of time. I'm assuming you're not one of them (I'm not either), and so you have to do what you can with what you've got.

Does this really work?

There are some examples from WinUI where community members (people) have suggested new controls and an alternate syntax that were then implemented by the team.

But what about something bigger?

The most prominent example I have of influencing a Windows-related open-source project is adding support for Visual Basic(!) in Windows Template Studio. This was a big deal as it was a significant change and would be something with long-term consequences.

This is something that I (as a non-Microsoft employee) persuaded Microsoft to add.

• I did this for a project in which I had built a reputation for regularly participating.
• I'd previously displayed knowledge so that the project leads valued my opinion.
• I backed up my suggestion with data. (Not data I had but data I knew they could get access to and assumed would support my proposal.)
• I suggested something that aligned with the larger goals of the project and organization.
• I suggested something that wasn't in my immediate interests but would help underserved members of the community.
• I showed how I could help make the change easy by volunteering to help with the work.

Only big changes?

Let me be clear, contributing to open-source isn't only about big changes!

Every little helps! It's not just true of supermarkets. All the small things we do add up. 

One of the great benefits and advantages of open-source software is that it can be built on many people's wisdom, knowledge, skills, and contributions. Not everyone can make large contributions (in size or number) to every project. But, all contributions help, regardless of size, when they work to build better software for everyone.

Improving documentation, giving feedback on a spec or proposed feature, adding a real-world example, and sharing details of a project. These can all be just as valuable as writing code.  

There are projects where I've only ever made small changes. Yes, even only fixing typos. I know these don't make a massive difference but they do help those who come after me and they do make a difference.

Start small and then work up. Or don't. Staying small is good too.

I drafted the first version of this post in early February.

As part of the WinUI Community Call on 17th February  2021, they included a section on "Maximizing Your Influence on WinUI." (Watch that section on YouTube)

There was lots of good advice in that call/video, and I think it complements what I've said above.

If you don't want to watch a 15-minute video, here are some screen grabs of the slides shown, or check out this document where they summarize the key points.

WinUI isn't a project where you can easily come in and make big changes, or expect dramatic changes in direction. But you can help make a difference, not only to the project but also to the lives of the developers and the people who use the software they create.

My impact on the spec process is the most significant change I've made there, but I'm not disheartened. I know I've made a difference that helps others and I hope that my contributions, suggestions, feedback, and support will continue to have a broader impact in the future.

Keep showing up.

Let's make a difference together.

It's sad and happy to deprecate something that's no longer needed.

A couple of years ago, I built a tool called UWP Design-Time Data (GitHub | NuGet)

It attempted to provide some functionality that was available in Xamarin.Forms (XF) but not in UWP.
I saw someone from Microsoft show the functionality available to XF developers and immediately wondered two things? When will that be available to UWP? And, how can I recreate that until then? 

Based on the limited XAML extensibility of Visual Studio, I did the best I could. It wasn't perfect, but it was better than nothing.

Mine was never meant to be a permanent solution.
I always expected and hoped for it to go away. The last time I gave a conference talk about XAML tooling (in Feb 2020), I even talked about mine being a temporary solution.

Version 16.7 of Visual Studio (actually released in the middle of last year) added this as part of several other XAML-related improvements.

Today I finally got round to updating the GitHub repo and Nuget listings.

I'm not going to take them down, but they're essentially deprecated, and I don't ever expect to update them again.

It's sad to think that this is the end of this project.
All the time and effort I spent on this has no future value.
Hopefully, at least some of what I learned in the creation and support of this will be useful in the future.
But, it's good to know that this small but useful functionality is now available to all VS users, not just those who hear about and install my extension.
It's also good that to think that I was able to help some people for a while.

Today is a time to celebrate what was and look again at what comes next. 🥂

Never just "should"!

 TLDR: never use "should" without explaining why.

Photo by Brett Sayles on Pexels

How many times today have you used the word "should"?

"You should do X."

"They should do Y."

"It shouldn't be like that."

Or any variation on that theme?

"should just" is even worse.

"You should just do X."

This use of "just" implies it's simple or easy to do. It implies little effort will be needed. But, that isn't always the case.

What may be simple for you may not be for someone else. 

What may seem simple from the outside belies what may actually be required to make it happen.

Avoid saying "just" when it implies simplicity unless it's something you're doing and already know how to do.

"Should" is more complicated.

You may be familiar with the MoSCoW method of prioritization. I was taught this at university and have never liked how vague and open to interpretation the categories still are. I've been in far too many meetings throughout my career that have come down to different understandings of what needs to be delivered. In these situations, "should" is either considered to mean:

• It would be nice if this was included, but it isn't strictly necessary. 
• It's used to indicate or identify something that can be deferred until another time.
• Or it's understood to mean something that can only be left out without a VERY good reason. 

"Should" can cause confusion.

Or, maybe you're used to seeing SHOULD in documents where it takes the definition from RFC2119.

. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

This is the crux of my issue. It admits that there are one or more reasons why something should or shouldn't be done.

If you say that "something should be done," why should it be done?

Because of your personal preference?

Because of a contractual reason?

Because of knock-on effects and dependencies or consequences elsewhere?

Without knowing the reason(s) that something "should" be done, we're forced to guess.

If the person saying "we should do X" has the ultimate authority to make decisions, then knowing why has less importance. It might be helpful, useful, or empowering to understand why, but it's not essential. 

In this scenario, a different word is more appropriate. "Please do X." is more specific and more helpful. Even if it's a bit abrupt, it's better than adding unnecessary and potentially confusing words.

If not direct instruction, knowing why is essential. If an opinion, we may be free to ignore it. If a contractual requirement, then we need to know to make sure it happens. If a pressing priority, time-sensitive or will have considerable consequences if not know and acted upon, then we need to know.

It might not be as severe as "you should stop that small child walking into traffic," but explaining why something "should" be done is considerate.

"You should do X" is rude.

"If you do X, it will help me..." or "if X is done first, it will unblock this other work" or "we need to make sure that we do X" are respectful and collaborative. 

Words matter.

You must be insane to be a software developer

"The definition of insanity is doing the same thing over and over again and expecting a different result." - Probably not Albert Einstein.

When debugging, I repeat myself frequently. Doing the same thing over and over again and hoping for a different result.

There are times I wish I had alternatives, but I know no other way, and so I rerun the code. Each time hoping that something will be different.

Rarely it is.

But it's those rare occasions that make this approach acceptable, if not necessary.

Note. I'm not talking about Heisenbugs. They're a separate, additional thing.

Sometimes repetition is the only option. An issue is observed or reported as only happening "some of the time." In such scenarios, the only available option is to run the code or perform an action to see when the bad thing occurs. Then try and identify what the difference was when it happened. 

This is important because, without consistent reproducibility of an issue, it's impossible to be 100% confident of an applied fix.

I know many developers and organizations who dismiss reports of occasional issues. If the problem doesn't happen all the time, so their thinking goes, it must not be with their software. Or they assume that the responsibility to fully identify the cause of the bug is not theirs. Or, they think their time would be wasted trying to reproduce such bugs consistently.

This comes down to perspective and priority.

Is the developer tasked only with writing the code? Or is the code a means to an end?  

I think the goal of writing code is to deliver value. I don't see any value being delivered by dismissing a bug report because it's not consistently reproducible. Instead, I see this as a challenge.

I assume that the person reporting the problem has given all the information they can. Now the challenge is for me to investigate the situation and find the solution. I'm a detective. 🔍

Being a bug detective might (and often does) mean repeating tasks to see when there is an inconsistent response and then trying to work out the cause. Such problems usually come down to one of four things.

• It's time (or date) dependent.
• It's machine/OS/configuration dependent.
• It's a race condition.
• It's dependent on the number of times the function is executed.

That time it failed, and the time before it worked even though the code hasn't changed. What else has changed? And how can I test that?

Note. I know there are obscure edge case bugs that it's not the best use of anybody's time to address. Let's assume that here I'm talking about bugs that the business deems worth spending time/money/effort fixing.

I wonder if there are better ways to investigate such bugs.

I wonder if there are tools to help with this. (I've found references to a few things that no longer exist but nothing current. 😢)

I will frequently run unaltered code and hope for a different result. Surely I'm not the only one...

Tried everything? - Methodical debugging

I've been thinking about "methodical debugging" and would love to hear your thoughts and experiences.

Tried Nothing GIF from Tried GIFs

Early in my career, I worked in a head office IT department. While the main focus of my role was software development (mobile, desktop, and web applications), I was also the last line of support for any problems.

If a customer had a problem, they'd contact the branch. If no-one at the branch could help (some branches had their own IT staff), it would be escalated to the helpdesk. If the helpdesk could solve the problem, they'd contact me.

When contacted by the helpdesk about an issue, I couldn't immediately answer, I'd ask, "what have you tried?" The answer to this was always "everything!"

This bugged me for two reasons.

1. It definitely wasn't true because if they'd tried everything, they'd have found the answer. Or if there was no answer, they'd know that too.
2. It meant they didn't have a list of what they'd tried, so I'd have to go right back to the beginning, assume nothing, work through all the possible issues, and find the resolution that way. This duplication of effort was inefficient and felt like a big waste of time.

In retrospect, I wish I'd taken the opportunity to define a list of questions that could be asked and things to document when they're asked. 

But I don't have a time-machine and can only think about improving things in the future.

And think about the future I have. Specifically about debugging.

My debugging has a tendency to be a bit haphazard. I'll skip from trying one possible idea to another until something works. I'll do my best to try and only change one thing at a time, but I can't be certain that's always the case. Especially if the issue isn't quickly resolved, I can easily forget all the things I've tried and suspect I may end up trying things more than once.

While this approach gets me to an answer, I'm not sure it is efficient, effective, or the best way to learn the most about what doesn't work or why.

There isn't a lot (I can find) written on the subject, and the little there is typically starts by acknowledging the lack of writing in this area.

This feels like an area that, if better understood, could greatly help many people in the industry.

What about you, do you do anything other than what I've described above?

If you document things as you debug, I'd love to know more about the process or technique you use and how it's helped you.

Aside: The role I mentioned at the top is where I developed the attitude that I must find the solution if there's a problem because there isn't anyone else to ask. This was before YouTube and StackOverflow. When I got truly stuck, there were only web-based bulletin boards and forums to ask for help, and these rarely proved fruitful. Even now, when I hit a problem, I usually stop and try and work it out myself before searching for error messages or the like. I find this approach valuable as it forces me to think more widely about the problem and explore ways to solve it. I've become a better developer by taking an attitude of "I don't know how to solve this yet(!), and in learning how to solve this, I will gain knowledge that helps me in other ways too." This is in contrast to an attitude I often see in others, which is to get the answer to the specific problem they are currently facing as quickly as possible and then move on.