Tried everything? - Methodical debugging

I've been thinking about "methodical debugging" and would love to hear your thoughts and experiences.

Tried Nothing GIF from Tried GIFs

Early in my career, I worked in a head office IT department. While the main focus of my role was software development (mobile, desktop, and web applications), I was also the last line of support for any problems.

If a customer had a problem, they'd contact the branch. If no-one at the branch could help (some branches had their own IT staff), it would be escalated to the helpdesk. If the helpdesk could solve the problem, they'd contact me.

When contacted by the helpdesk about an issue, I couldn't immediately answer, I'd ask, "what have you tried?" The answer to this was always "everything!"

This bugged me for two reasons.

1. It definitely wasn't true because if they'd tried everything, they'd have found the answer. Or if there was no answer, they'd know that too.
2. It meant they didn't have a list of what they'd tried, so I'd have to go right back to the beginning, assume nothing, work through all the possible issues, and find the resolution that way. This duplication of effort was inefficient and felt like a big waste of time.

In retrospect, I wish I'd taken the opportunity to define a list of questions that could be asked and things to document when they're asked. 

But I don't have a time-machine and can only think about improving things in the future.

And think about the future I have. Specifically about debugging.

My debugging has a tendency to be a bit haphazard. I'll skip from trying one possible idea to another until something works. I'll do my best to try and only change one thing at a time, but I can't be certain that's always the case. Especially if the issue isn't quickly resolved, I can easily forget all the things I've tried and suspect I may end up trying things more than once.

While this approach gets me to an answer, I'm not sure it is efficient, effective, or the best way to learn the most about what doesn't work or why.

There isn't a lot (I can find) written on the subject, and the little there is typically starts by acknowledging the lack of writing in this area.

This feels like an area that, if better understood, could greatly help many people in the industry.

What about you, do you do anything other than what I've described above?

If you document things as you debug, I'd love to know more about the process or technique you use and how it's helped you.

Aside: The role I mentioned at the top is where I developed the attitude that I must find the solution if there's a problem because there isn't anyone else to ask. This was before YouTube and StackOverflow. When I got truly stuck, there were only web-based bulletin boards and forums to ask for help, and these rarely proved fruitful. Even now, when I hit a problem, I usually stop and try and work it out myself before searching for error messages or the like. I find this approach valuable as it forces me to think more widely about the problem and explore ways to solve it. I've become a better developer by taking an attitude of "I don't know how to solve this yet(!), and in learning how to solve this, I will gain knowledge that helps me in other ways too." This is in contrast to an attitude I often see in others, which is to get the answer to the specific problem they are currently facing as quickly as possible and then move on.

100,000+ "thank-you"s

At some point in the last couple of days, I passed a milestone. 

The public* packages I have made available on NuGet have now been downloaded over one hundred thousand times.

In the grand scheme of things, this isn't a large number. There are many packages with hundreds of thousands of downloads. Some of those packages get more downloads on an average day than my packages have had over several years.

So does this seem like a milestone even worth acknowledging?

I think so.

The above figure represents thousands of people (developers--they are people too) who I've been able to help save time and effort. It may be with a trivial, one-off task, or it may be something they use multiple times a day and in apps used by thousands of people. 

Download numbers like this are only relevant to the packages and the people who make them. I've known some developers over the moon because they never expected even a few hundred people to use the thing they created. In contrast, I've known other developers complain that the thing they created didn't get millions of downloads in the first few days.

This is a bigger number than I ever expected to reach but I also expect to produce many more packages in the future. Little by little, as I stick around and keep doing the work, the numbers go up. 

These tools may not have made a dent in the universe but they probably contribute to a small dimple. Maybe, over time, more dimples will add up to a dent. 

They may not be the most popular packages in the world. But that's not what I set out to create. I saw gaps where tools would be useful and produced tools to help with those situations. A small gap in the market that one person can quickly fill will rarely become massively popular, so I had set my expectations accordingly.

However, a niche product can be really useful to people who need it.

Many of these packages are now redundant (because they relate to platforms that no longer exist--the platforms aren't publicly available or supported in any way) but these packages serve as a reminder to myself (and maybe others) that I'm here for the long term. I haven't just shown up in the open-source world, made something quickly, and then gone away. It's also a reminder that small gaps can also be worth filling. Not only do they help with the things that I work on but they are also useful and helpful to others too.

I think the above figures help quantify part of my contribution to making the world a better place through open-source software.

Of course, my contributions aren't just about niche tools for underserved platforms and environments. I also contribute to much larger projects too. Some with many millions of downloads.
The combination of working on a breadth of smaller scenarios with my tools and much larger projects as part of a group of contributors, helps me become a better developer.

* There are a couple of private ones I have removed ("unlisted") because of name and dependency changes. They definitely shouldn't be used.

Here, I made this to search StackOverflow for your error description

Another small update to an existing Visual Studio extension.

ErrorHelper allows you to work more easily with the descriptions on the Error List.

You can copy the description (not just the whole line--as is the default behavior).
If the description contains a URL you can open that directly.
And you can search the internet for the description (error) message.

The alternatives to using this extension is to manually type the error message or URL. Or you can copy the whole line (including all other columns) paste it somewhere and delete the bits you don't want, or copy (again) the bit that matters and paste that into a search box somewhere else instead.

I find right-clicking and then clicking on "Search Description" much faster and easier!

In today's update (v1.7), I added the ability to set the search engine as StackOverflow.

Yes, searching in Bing or Google quite often takes you to StackOverflow. If you find that's the case for you, this option now cuts out the middle-man.

This improvement was from a suggestion I received on Twitter. If you have any other ideas for making this (or any other extension better) then feel free to tweet me a suggestion too. 

Here, I made a thing to save time building all projects in a solution

Compilers are complicated. They don't always behave the way you'd expect.

For instance, if you have a resource that has the Copy to Output Directory setting of Copy Always this can force a whole compilation even if nothing has changed!

I've never needed this but sometimes this is the default setting for some file types. As this can lead to me waiting while projects are being unnecessarily recompiled I previously created a Visual Studio extension to detect this and warn me so I can correct offending entries and save myself time.

Today I've updated it so that it can be used from the context menu of the Solution entry in Visual Studio's Solution Explorer.

Just a little thing but I hope it will help at least one person.

 :)