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.