Wednesday, January 12, 2022

Reasons to ask a question

I've been thinking a lot about communication (I know--fun, right?!) and especially about questions. This is because asking and responding to questions (not just answering them) is a large part of communication.

So, 11(+) reasons to ask a question:

  1. To get an answer.
  2. To force others to think about the question's topic.
  3. To encourage someone to think about how they'd answer (even if they don't.)
  4. To get attention. 
  5. To get a response (that isn't a direct answer.)
  6. To show (admit?) that you don't know (everything.)
  7. To show a willingness to learn.
  8. To show that asking questions is good/ok/acceptable/encouraged.
  9. To show an example of questions that can be asked.
  10. To show that you've thought about (or researched) the subject enough to be able to ask smart, informed, appropriate questions.
  11. Never for no reason. 
  12. Other?

I know the above is a generalization, and it won't apply to all scenarios but is a helpful summary of the things to consider.

Thursday, January 06, 2022

Template Studio for WPF

Following on from UWP, I've now released a preview of Template Studio for WPF.

Why WPF? - Because it has a similar position within WinTS as UWP. That is, it is (I suspect) less likely to have a future in WinTS which is likely to (again--I suspect) continue to be increasingly focused on WinUI.

WPF also has an opportunity for a longer life than UWP. Because of this, I plan to extend the provided options and add the ability to create WPF apps that are based on .NET 6.

More importantly, to do this I've got the codebase to a place where it can produce multiple different extensions that build for different platforms and happily work side-by-side. This opens the door for lots of exciting new things going forward. (hint hint)

Anyway, give it a try and let me know any feedback.

Wednesday, December 22, 2021

I've found a bug in your open source library but I'm not going to raise an issue to log it. Sorry.

I suspect many people think this but never say it. 

It comes down to one simple fact: I haven't got the time.

"New Issue" button (from GitHub)

I know many people will be upset with me for saying this. I also know that I've been disappointed by others who have expressed or displayed this attitude themselves.

So, why aren't I going to report the bug/issue/problem I've found?

These aren't always the case but usually:

  • I assume that what I've found is an edge case. (If it wasn't someone else would have logged this previously---I recognize that if everyone thought this nothing would ever get reported.)
  • I don't expect it to get fixed. (This is often tied to it being an edge case.)
  • I've already spent lots more time on this than I wanted to (can really afford to) so another unplanned task related to this doesn't feel like a good use of my time. 

Expanding on that last point, a good bug report takes time to create. It depends on the project and the issue but for something non-trivial, I've found this can often take me several hours.

If what I've found is trivial to explain and recreate then creating a bug report or issue is simple and I'll always try to create one.


If it's not simple to explain and recreate, creating a bug will likely be a waste of my time and effort

Creating a bug/issue doesn't help me with the project I'm working on. I've just created a workaround that works with the code I have now. 

If the issue is fixed in the project I'll need to spend more time verifying the fix and (possibly) removing the workaround I've had to use.

Having found a workaround that meant spending more time than originally planned, I'll have to spend more time creating a bug (& repro), and then possibly spend even more time verifying a fix and making any necessary changes. Stopping once a workaround is found is often very appealing.

But what about other people who may encounter this issue?

Yes, creating an issue for them to find may help them. If I can share a workaround then even better.

If not an issue, maybe a blog post explaining the workaround would be something faster to create. That way at least there's a document somewhere on the internet for others to find. Sadly, very few scenarios (or projects) warrant (or allow) a brief description of a problem and a workaround.

If my aim is to make the best use of my time to help others, documenting a workaround for an obscure edge case doesn't feel like a good use of my time. Surely there are things I could do that would help more people...

This situation isn't good for anyone.

I don't want it to be like this.

I wish quick, simple bug reports were acceptable. - Even just a brief description that could be expanded upon over time. However, a description without a simple reproduction is likely to get closed rather than left open waiting for more details.

If it was an open-source project, I'd be happy to create an issue that has a description of the problem and a workaround (or link to one if documented elsewhere).

Having detailed instructions on how to report issues including having requirements on creating/including minimal ways to reproduce an issue are appealing from the perspective of a maintainer but are offputting for a person who just wants to use the library/tool and doesn't have the time to create a detailed report. 

Or could there be something better?......

I don't have any answers. 😢

I just wanted to start documenting my thoughts on this subject. I expect to have a follow-up post to this, eventually.

As a project maintainer, I'd rather know about any problem, no matter how vague or seemingly lacking in details. Knowing that something's wrong is preferable to not knowing.

At best it might indicate a gap in the documentation.
At worst it means a vague issue remains open. Possibly indefinitely.

Admittedly, if I had millions of users and loads of vague issues being created I may think differently.

Let me try and be clear (although being very aware the people I've most upset will probably not make it this far before saying something rude about me):

  • I want the tools I use to get better, add features, fix bugs, etc.
  • If I can and if you make it easy, I will raise issues.
  • If you make raising issues hard I'm much less likely to do it.
  • I know you're busy and your time is valuable. So is mine.
  • If you want to report an issue with one of my open-source projects, I'll happily take as much (or as little) detail as you can provide. The more detail you provide the more likely I am to be able to do something about it. But, I'd rather know there was a problem, even if it can't easily be recreated (yet!)
  • I'm aware this approach may not apply to very large projects. (If only this was my problem.)

Thoughts? tweet at me

Tuesday, December 21, 2021

Are technical computer books supposed to make you laugh out loud?

If you are using the digital version of this book, we advise you to type the code yourself or access the code from the book’s GitHub repository (a link is available in the next section). Doing so will help you avoid any potential errors related to the copying and pasting of code.

Honestly, I laughed out loud when I first read this.

Do you find manually retyping something (already in a digital format) less error-prone than copying and pasting?

cut, copy, and paste icons

Am I unusual in finding copying (& pasting) something being less likely to result in any potential errors than typing it myself?

I get that typing something yourself can help when you're learning something and want to be clear about what code you're adding and why. But, cutting and pasting has always been less error-prone than typing.

Monday, December 20, 2021

Questions to ask BEFORE asking a question

I've been thinking a lot about communication (I know--fun, right?!) and especially about questions. This is because asking and responding to questions (not just answering them) is a large part of communication.

So, 10(+) questions to ask yourself before asking a question:

  1. Can I work out the answer myself?
  2. Can I find the answer myself?
  3. Will the person I'm asking know the answer?
  4. Can they know the answer?
  5. Will they be able to give me an answer if they know?
  6. What will it cost them to answer?
  7. Will this impact my ability or opportunity to ask other questions?
  8. Will others want to know the answer?
  9. Have others asked the question before? and what, if any, answer did they get?
  10. Why isn't the answer easily/already available?
  11. Other?

I know the above is a generalization, and it won't apply to all questions but is a helpful summary of the things to consider.

Not all are always relevant, appropriate, or useful, but all are worth considering before asking (or even answering) a question.