trivial feedback and micro-optimizations in code reviews

When these are given, is it because there is nothing more important to say?

Or, does such feedback come from people who don't understand the bigger picture or want a quick way to show they've looked at the code without having to take the time and mental effort to truly understand it?

Before commenting

Are you just repeating what's already been said before?

Where/when appropriate, are you correctly attributing others?

Does your comment add value?

Are you adding a new/different/unique perspective?

Have you read the other comments first?

Have you thought about who (possibly many people) will read the comment?

MAUI App Accelerator - milestone of note

In the last few days MAUI App Accelerator passed ten thousand "official" unique installs.

This doesn't include the almost eight thousand installs included via the MAUI Essentials extension pack. (Installs via an extension pack are installed in a different way, which means they aren't included in the individual extension install count.)

While big numbers are nice (and apparently worth celebrating) I'm more interested in how it's used.
The numbers for that are lower, but still noteworthy. 

It's currently used to create about 25 new apps each day. Which is nice.
I'm also trying to improve my ability to use App Insights so I can get other and better statistics too.

More updates are coming. Including the most potentially useful one...

"I'm not smart enough to use this"

 I quite often use the phrase "I'm not smart enough to use this" when working with software tools.

This is actually a code for one or more of the following:

• This doesn't work the way I expect/want/need.
• I'm not sure how to do/use this correctly.
• I'm disappointed that this didn't stop me from doing the wrong thing.
• I don't understand the error message (if any) that was displayed. 
• Or the error message didn't help me understand what I should do.

Do your users/customers ever say similar things?

Would they tell you?

Are you set up to hear them?

And ready to hear this?

Or will you tell me that I'm "holding it wrong"?

Don't fix that bug...yet!

A bug is found.

A simple solution is identified and quickly implemented.

Sounds good. What's not to like?

There are more questions to ask before committing the fix to the code base. 

Maybe even before making the fix.

• How did the code that required this fix get committed previously? 
• Is it a failure in a process?
• Have you fixed the underlying cause or just the symptoms?
• Was something not known then that is now?
• Could a test or process have found this bug before it entered the code base?
• Are there other places in the code that have the same issue?
• Are there places in the code that do something similar that may also be susceptible to the same (or a variation of the) issue?
• How was the bug reported? Is there anything that can be done to make this easier/faster/better in the future?
• How was the bug discovered? Can anything be done to make this easier, more reliable, or automated for other bugs in the future?
• In addition to fixing this bug, what can be done to prevent similar bugs from happening in the future?
• Is there anything relating to this issue that needs sharing among the team?

As a developer, your job isn't just to fix bugs; it's to ensure a high-quality code base that's as easy (or as easy as possible/practical) to maintain and provides value to the people who use it.

At least, I hope it is.