Of course documentation shouldn't be like this!

Publishing this several months after I wrote it - the issues were eventually addressed and I managed to unblock myself.

Four views of XAML development

Having spoken with hundreds of developers about XAML development, they almost all fall into one of three groups:

1. They've been using it for a long time (many years) and have grown happy with how it is. They can be productive and aren't interested in change.
2. People who don't like it and have decided to use something else instead.
3. People who begrudgingly use it, moan about some of its "quirks", and don't feel as productive as they would like to be.

If you're in either of the first two groups, that's great. Use what works for you. Be productive, build great software, and enjoy your life. The rest of this post is not for you. 

Group three is by far the biggest group. At a[n educated] guess, I'd say it's easily more than 90%.

I count myself in a 4th group. (Not just because I'm "special".)
I use XAML, but what I write doesn't look like the XAML that I see online, in demos, samples, and other people's codebases. The code I write is a lot shorter, clearer, and easier to maintain.

Part of what makes this possible are the tools I've created to help me. (Considering the challenges they face, that so few others do this, surprises me.)

But tooling has only gotten me so far.
Another language may be more beneficial.
But not one that requires a rewrite. Something that works with my existing code and also helps with new files.
Something that can enable experimentation without the risk of being stuck with code in an unsupported language and so can't be tried/used in "real" projects.

It sounds almost too good to be true.

Why do I care about XAML if I have such seemingly lofty software development goals?

Wanting to improve things for many people using software by providing better tools for developers may seem at odds with my focus on XAML. Afterall, XAML is a relatively small language only used for making native (mobile and desktop) apps by people building with .NET.
If I wanted to really make a big impact, why not look to do something online? or with AI?

Yes, more people use web-based technologies than use XAML.

Yes, AI has the potential to make a massive change.

However, many people are focused on these areas, and I don't want to get distracted by something new and uncertain.

I know XAML and its related technologies very well.
Very few other people are working to make working with it any better/easier.
It may not be a big niche, but it's overlooked by most, so I can (hopefully) make a big (relatively) difference with my efforts.

The people who use desktop and mobile apps deserve the best software, just as much as those using the web. 
The developers who build and maintain that software also deserve the best tools.

There's also a lot of such software already in existence. 

Software becomes old because it continues to be valuable to a business. If it wasn't, it would be scraped or replaced. That so much of this software is around highlights its value and importance.

Rewriting old software isn't always practical, but it still needs to be updated and maintained. Making that easier (faster and with fewer risks of unexpected consequences to changes) can be a big win.

For companies with a lot of existing software, being able to use the existing skills and knowledge in new software is very appealing. Building new apps faster and in ways to avoid future maintenance fears is another big win.

Secretly (I'll tell you because I like you), focusing on this area is fairly low risk.
I'm demonstrating an understanding of businesses and how programming languages are used within them. I also hope I'm showing an understanding of developer wants and needs and my ability to create sophisticated solutions to meet those challenges.

Even if all XAML development went away or I had an opportunity to work on something very different, I'm confident I'm building (and demonstrating) useful skills for the future.

Software development as "creative problem solving" - and me.

The following is inspired by multiple interviews with actors and comedians. - Yes, I find software development inspiration in unusual places.

A motivated person who wants to make it in the 'arts' will typically have to do many things by and for themselves.

This means being a creative problem solver.

Want to put on a show but don't have a stage, set, or costumes? - Work something out!

Want to make a film but only have a tiny budget? - Get creative!

Want to try something entirely new and different that no one has thought about before and that everyone says is impossible? - Find a solution! Help others see your vision!

These are also the aspects of software development that I love best.

While software can do "anything", such a broad set of options is rarely helpful. Constraints are real, and they drive innovation and creativity. The constraints often lead to discovering that something isn't as impossible as originally thought.

There may be a need for people to build software that is the same as (or a tiny deviation from) what already exists, but I don't want to do that.
Not because it's beneath me but because it doesn't excite me.

I've previously particularly enjoyed projects along the lines of:

"We need it to do X but can't use [the only way anyone has ever done X before]."

or

"We only have 5 weeks to build [seemingly large and complex series of connected software], or we miss out on a massive opportunity for the business."

or

"We want it to do Y, but as no one has ever done that, we don't know if it's possible and can't (yet) see how to do it."

There are two ways such projects can be even more satisfying (to me):

1. When I get to see and hear how the created solution helps people and improves their lives. Even if only in a small way. 
2. When I'm creating something that helps improve things for other software developers. This is because improvements for them are multiplied into more, higher quality software that is beneficial (or even "just" less frustrating) to many more people.

This is, possibly, why I've recently refound an enthusiasm for the possibilities that come from creating software.

2024 wasn't a great year for me. I left what was initially a very exciting project as a team was formed around the work I'd started. As I felt the project moving backwards, it became frustrating and unproductive, and so I stepped away, wondering if this was even an industry I wanted to stay in.

Side note. Many months later, a simpler version of the project was launched, which received much acclaim and positive reactions. Hopefully it will go on to be very helpful to a lot of developers, but I can't talk about it in any detail.

I planned to take some time off and reassess my career plans.

That's not how it played out, as I sustained a physical injury that meant I had six months where all I could do was sit (literally) and watch the world (and work) go by.

It was like a miniature version of the COVID-19 lockdowns, but just for me.

Upcoming plans were cancelled. These included career goals, planned jobs, and events I'd been looking forward to for months (and even years in one case.) It was not a happy time.

At the start of 2025, when once again mobile and recovering well, I determined to forget the past year and try and find not only paid work (because bills don't stop when people do) but something that would excite me again. A way to use my creative problem-solving skills that could help other developers improve the overall quality levels of the software in the world.

As my experience is with native (rather than web) technologies and because I've spent a lot of time over the last few years thinking about how it can be easier and more productive to work with XAML, I've been thinking about that once again. As I refine what I would have previously thought was "too big an idea for me", I also look forward to sharing more about that soon.

Job titles in tech compared with other collaborative work in creative industries

Ok, that sounds like a boring and almost academic title, but this is about how filmmaking, food, and events can help me think about creating software.

Look at all the names that are displayed in the credits at the end of a movie.
So many names, each with a specific title, and each title implying a specific set of tasks. Those tasks may each require a specific set of skills, talents, and abilities.
It's not just a random assortment of names under a general title such as "team" (or "organized by").

Those titles aren't just labels or descriptions; they are also signals to others working in the production.
They also serve as a way to clearly communicate with people outside the group. This includes customers, partners, contractors, people they are doing business with, and the wider industry (including potential future employers and collaborators).

The roles/titles all have defined meanings, even if they're unclear to people outside the industry. (Do you know what a "key grip", "best boy", or "2nd Assistant Director" is or does?) Despite the different titles in the credits, these people may also call themselves 'filmmakers'. Even if they're not the director or doing everything themselves, they are still contributing a vital part to the process.

Or consider a large professional kitchen. Again, everyone has very specific roles that may also require particular skills or knowledge.
But during service, everyone in the kitchen is a 'chef' and is called that. Sometimes, this also includes front-of-house staff while in the kitchen.

The shared title is a mark of respect and acknowledges the need to collaborate and the values that different people bring. This is especially true when only one person is the public face of the work that took many.

Then there's the software industry.

Every company seems to have their own job titles with their own meanings. These may or may not bear any resemblance to the use of the same title by another organization.

Software "teams" are notorious for being highly separate and communicating poorly with the broader organization. There's also rarely a shared, collective responsibility that cuts across teams. 

Many people working in software creation are also dismissive of people in other roles. "Oh, they're just in the [department or team name]." Or, "They're just a [job title]."

These are the thoughts and impressions I have gained throughout my career.

I'm sure it's not everyone, but I hope it improves.

I enjoy working on solo projects, but I also like the idea of once again working on a large, cross-discipline team to help create great software.
Here's to hoping I find that soon.