Thursday, February 22, 2024

Why AI (LLMs) is not the solution to your problems with XAML

If you work with XAML (or you've tried to) you might think of it as being verbose, long, and hard to maintain.


For many people, AI is a solution to many technical problems. Working on the basis that if you can describe what you want or start writing it, the "AI" can generate what it thinks is likely what you want.

This is great if you're doing something that has been done many times before or you want to do something new in a very similar way to what already exists.

If, however, you aren't keen on what already exists or have complaints or concerns about the way things are currently done this isn't going to help. "AI" works by looking at existing data (mostly the contents of the internet for general-purpose and public AI services) and creating based on that.

But, come back to XAML. The criticisms aren't as much about writing the code, they are more focused on reading and modifying it. Having the code written more quickly doesn't address the problems of reading, understanding, and maintaining it. Tasks that are widely accepted to be what most developers spend most of their time doing.

If you want XAML that is easier to read, understand, maintain, and modify without unexpected consequences, you need to think about writing it differently. 

"AI" is great at giving you things similar what already exists, but if you don't want more of the same (and when it comes to XAML I don't think you do) now might be the time to start thinking about writing XAML in a different way....




Thursday, February 01, 2024

That's not what code reviews are for!

So, you're reviewing some code.

Here are some things you shouldn't be doing:

  • Leaving comments just to prove you've looked at it.
  • Commenting on existing parts of the code base not directly related to the specific change/PR.
  • Checking the code builds - CI should do this before you review anything.
  • Checking the tests run (& pass) - CI should do this before you review anything.
  • Checking that coding/styling/formatting conventions are met - tooling should enforce this, not you!


Instead, here's what you should be doing:

  • Verifying the code does what it's supposed to do?
  • Verifying the code does not do anything it shouldn't?
  • Checking the code doesn't introduce any new issues/bugs/potential future problems.
  • Confirming that you'd be happy to support and maintain this as part of the code base.
  • Ensuring that any follow-up work (including accrued technical debt) is appropriately logged. 


These are not complete lists, but hopefully, they are still useful.


Wednesday, January 31, 2024

I don't want to be interesting

Do Interesting: Notice. Collect. Share - by Russell Davies

This is a great book. I heartily recommend it. However, I don't think it's interesting.


I don't think it's interesting because I don't like that word. 

"Interesting" is vague.

"Interesting" is meaningless.

"Interesting" is a word people use when they don't know what else to say.

Try it. Next time someone tells you about something "interesting", ask them what made it interesting or why they thought it was interesting.

Or consider when someone tells you they "have something 'interesting' to tell you." Is it really interesting? Or is it gossip? Or is it something they don't have a better description for?


"Interesting" is unspecific and unconsidered. Not the book, the concept.


 That's not what I want to be, or do, or be thought of.


Here are some much better adjectives (in no particular order):

challenging
inspiring
thought-provoking
troubling
upsetting
motivating
fascinating
amusing
entertaining
captivating
encouraging
intriguing
inviting
gripping
impressive
restorative
engrossing
enchanting
enthralling
spellbinding
diverting
attractive
rousing
persuasive
provocative
stimulating
stirring
exceptional
exciting
unforgettable


Don't those sound more appealing?


It's the first three items on that list (challenging, inspiring, thought-provoking) that I think apply to that book, too.



Wednesday, January 24, 2024

Lessons from mobile notifications applied to IDE Extensions

TLDR: If you want to prompt "the user" to do something, let them get value from what you provide first.

Dog with pleading eyes

Photo by Jennifer Latuperisa-Andresen on Unsplash

Mobile apps want ratings and reviews. These are also valuable for open-source projects. This applies in a marketplace/store or as libraries/bundles/packages for download.

Increasingly, in the open-source world, the issue of sustainability is also a consideration.

Among other things that contribute to sustainability is financial support.

I use a variety of approaches across my open-source projects to try and encourage such compensation via Google Sponsors.

It doesn't make a massive impact on my finances but it has been enough to make a difference and was also the only way I could afford an unexpected tax bill when I was out of work during the pandemic!
Regardless of the amount or duration, I will always be grateful to those who have (and still are) sponsoring me. Thank YOU!

Yes, I ignore the amount and duration. All my sponsors get access to the same benefits, be it a one-off amount of $1 or recurring amounts of much more. (I previously did more analysis of these differing durations and amounts.)


Anyway, one of the approaches I use to encourage people to consider becoming a sponsor is a message displayed in the output window asking them. (If they do, I also tell them how to make such a message not appear.--No phoning home. No personal data is collected. 😉)

This approach isn't appreciated by everyone but seems to be very effective, as I have more people sponsoring me than most other people I'm aware of who casually contribute to open-source projects.

My approach to monetizing my projects is very much inspired by donationware, and most software made available in this way doesn't hold back from asking for donations. 

I had been following this approach but wondered if a different technique might be more effective.

In the latest update to my C# Inline Color Vizualizer extension, I changed the behavior determining how visible the encouragement to become a sponsor is.

Instead of always displaying the message to the user, it loads it in the background but only actively shows it once it is at least 7 days since it was first used and it has been used to annotate at least 100 files. The goal is to let the person become familiar with seeing the benefits of using the tool before asking anything of them. The theory is that they will then be more inclined to respond to the message.

I must have said and heard the same advice applied to mobile notifications hundreds of times but had somehow overlooked its wider application.

If you're not familiar with the extension, it adds examples of the. Like this. Why not give it a try?

Partial screenshot of the VS editor showing what the specified color looks like.

I plan to add similar changes of behavior to my other Visual Studio extensions as is appropriate to the way they work and what they do. I'll share details here if it proves effective or I learn anything insightful.


It's not only about the money I get. I like that this encourages more people to think about the sustainability of their tools. I think such messages do this, and the fact that most of my sponsors aren't sponsoring other people (yet) makes me hope that I'm just the first of many or that they find other ways to support the software they use (if not rely on.)


Sunday, January 14, 2024