Why I'm a [statistically] bad but also valuable developer

On one of the teams I've recently been working with, we have a channel in Teams for asking questions if you get stuck.

Officially, the guidance is that you shouldn't stay stuck for more than 15 minutes without asking for help.

The intention is that no one should be stuck for long without making progress.

I noticed that I was posting there more than most.

A quick review of the posts there in the last two months, and yes, I post there, asking for help, more than 15 times as often as other team members.

Some people manage to go months without asking for (or needing?) help!

I actually post on that channel more than I might. In starting to write about what I've already tried, I often come up with other ideas to try, and they sometimes pay off. (Maybe it would be more appropriate to rename it the "rubber duck" channel.)

15 minutes isn't very long to get stuck on something. Some of the things I've been working on recently are highly complex and can take hours to try the likely possible solutions I can think of.

But, as soon as I get stuck I ask for help.

There's no point asking for help when I haven't tried the things that are likely to be suggested. But once they're exhausted (and documented if I need to share them with someone who might be able to help) I ask for assistance.

When working as part of a distributed team, asking for help, even asynchronously, as soon as it's needed, is an important and valuable skill.

You don't want to be that person who waits to be asked if they're stuck or struggle for days without making progress. Such people are rarely good for a team.

We'd all love to never need help, but we can't all know everything. 
If you're doing new things (which may be most of the time) then you're bound to encounter things you don't know and need assistance with.

Asking for help isn't (or shouldn't be) a problem. It's the people who don't ask for help that you need to watch more closely. They may be brilliant. They may be struggling.

Yes, my initial statistic doesn't allow for anyone asking other people for help directly. I can't measure that. But I do know that in large, distributed teams, it's hard (impossible?) to know who is the expert on every topic and who will be able to provide the quickest response due to time zones and flexible working patterns.

"Why an MVP shouldn't use their extensions to hijack a developers GeneralOutputPane in Visual Studio to solicit sponsorship and to use it as their own personal advertising space via a class called SponsorRequestHelper.cs."

And the answer is...because entire teams will no longer use the extensions. Because its not cute, it's distracting. Because it's not witty, it's inappropriate. And because I don't believe that blackmailing developers with removal of the nag once they sponsor you is very becoming of an MVP. While I was looking forward to using some of your extensions after a MAUI webinar I attended the other day, sadly, our team will not be using any of your extensions. And hijacking these special method handling attributes is irresponsible, because Im pretty sure Microsoft wont agree that your desire for sponsorship is in any way SPECIAL or more important than the runtime in which you are hijacking.

MAUI App Accelerator v1.4

Consider this a low-key announcement that version 1.4 of MAUI App Accelerator is now available in the Visual Studio marketplace.

This version adds support for building apps with .NET 8.0. 

Replacing occurrences of "net6.0" with "net8.0" might seem very simple, and probably is, but there was a lot more involved in the changes for this new version. 55 commits were made over 286 files.

There's also been significant testing involved. Combinations of all available options and just a single page produce 570 combinations in a generated app. And I also have tests for combinations of pages too!

A massive thank you to everyone who supports me via GitHub Sponsors. As a one-off or on a recurring basis (for any length of time), all sponsors make a massive difference and are a great encouragement. It's a pleasure to add each [non-private] sponsor to the list whose avatars are included at the bottom of the wizard.

When some people are so critical and demanding of open-source projects and developers (more on this soon), it's great to know that there are people who are supportive and encouraging of what I do.

Is MVVM still relevant or useful?

Thinking out loud (or rather through typing) here.

The MVVM pattern has a problem: everyone has a different definition of what it is and how it should be implemented.

"Everyone" thinks their understanding is the correct one, and doing it a different way isn't the "proper" way of doing it.

It was always intended as a loose structural guideline and principles rather than as a highly prescriptive way of writing code.

Maybe it's just me, but I still hear more discussion and focus on the use of MVVM as a "framework" than on other aspects of making a great app and creating an easily understandable and maintainable codebase.

Two key benefits that MVVM was initially intended to provide don't seem all that relevant either.

Reuse - When a ViewModel was referenced in separate solutions that each targeted a different platform, abstracting logic away from the UI to easily be reused in multiple solutions/apps made a lot of sense. When using MAUI, Uno, or Avalonia--where a single solution can produce apps for multiple platforms--using an architecture that structures code for reuse when none is needed risks adding unnecessary complexity.

Testability - most ViewModel code (still--sadly) goes untested. If you're the exception, congratulations. So, doing something for the sake of testability but then not creating tests seems a bit unnecessary. (At best.)

So what to do instead?

I don't have a single answer.

I know there are things like MVU and MVUX, but I just wanted to write this to get my subconscious thinking about the idea...

One test is never enough!

One part of creating coded tests for software is being able to know when something doesn't work as it should, not just confirming that something does work as expected. 

Imagine if you didn't. Consider a test that tries to verify that given X input you get Y output.

If you write a single test for this, you might be confident that when you input X, you do get Y out.

But, what if you input Z and still get a Y out when you shouldn't?

You probably also need a test for Z input too.

Actually, even having two test cases probably isn't enough.

If you're testing more than a simple boolean input, there are a lot more cases that you should probably be testing too.

I thought this went without saying.

I guess not. 

So now, I've said it.