Here, I made a way to navigate between ANY files in Visual Studio

Being able to navigate between different parts of code is really useful. You simply hold down the ctrl key and click on an item, and you're taken to the definition of a method, or class, or whatever. Or, maybe you use a shortcut or context-menu entry to do the same. However you do it, it makes navigating a codebase much easier and saves untold time.

But what if you want to navigate between files that aren't all code, or in the same programming language?

Visual Studio doesn't support this, but don't worry, I can help. 

Introducing CommentLinks, a Visual Studio extension to enable links between any files from within the Visual Studio code editor.

The idea is simple. In your code, you put "link:" followed by a filename, and then a button (see below) is added that, when clicked, will take you to that file.

It will search for files anywhere in the solution. The file doesn't have to be in the same directory, project, or in any project. It just needs to be visible in the Solution Explorer.

If there are multiple files in the solution with the same name, you can specify the one to find by including the directory name(s) to be clearly unique. e.g.:

link:otherjs\device.js

or

link:otherjs/device.js (either directory separator)

Want more than simply opening a file?

You can open the file at a specific line by adding "#Lnn" (where nn is the line number) after the file name. e.g.:

Link:plainfile.txt#L33

You can open a file and search for specific text by including it after a colon (:) immediately after the filename. Or after "#:~:text=" to match the convention for text fragment anchors.

link:device.js#:~:text=Device.prototype.getInfo

link:device.js:addConstructor

And, it can handle spaces in the search text or filename by using percent-encoding (so a space character is replaced with "%20") or by putting them in quotes (single or double.) e.g.:

link:device.js:"getInfo = function ("

link:"device.js:getInfo = function ("

link:"name with spaces.js"
link:misc%20files/other%20device.js

You can navigate within the same file (to search for subsequent occurrences of text) by specifying the file's name and then the search text.

You can open any file on disk by specifying the full path. e.g.:

link:C:\Temp\TestFile.txt

You can even use it to run arbitrary commands by adding "run>" after "link:" This can be useful to open other applications, open files in their default application, or to run commands with custom schemes/protocols. e.g.:

link:run>cmd.exe

link:run>mockup.pdf  (assuming in the same directory)

link:run>ms-settings:easeofaccess-highcontrast

Don't want to use "link:" before the file name?

That's ok. You can change this to any text you want by going to Tools > Options > CommentLinks and changing the Trigger word.

The name might be misleading. It doesn't just work with comments but anywhere in the code file. The name came from the original intention and the fact it was expected only to be used in comments. It works anywhere.

Get it from the marketplace and let me know what you think.

Want to see it in action? See this quick video I made previously showing some of the features.

This is part of a collection of Visual Studio extensions I have made. You can see them all at https://marketplace.visualstudio.com/publishers/MattLaceyLtd 

I originally created this at the suggestion of one of my GitHub sponsors. Not only am I really grateful to the people who sponsor me (the current ones and those who have sponsored me for a period of time in the past, but I also try and do things to help them.

I can't always build everything my sponsors want or need, but I'm inclined to help them more. 😉

This was built for a specific niche use-case, but other people have already found this extension and requested many of the features it has. It turns out that working with multiple file types in VS isn't something that everyone needs to do, but the people who have to do this are very disappointed with what comes in the box and are keen to see additional capabilities added.

One such person who wanted a new capability even paid for this to be added. They wanted a feature I wasn't sure about adding. I was going to suggest to them that this was the sort of thing I'd be more inclined to do for a sponsor, but before I could email them, they'd sent me some money. Not a lot but not a trivial amount. That feature was added quickly ;)

I'm still not entirely sure how I feel about someone giving me some money and then asking for a feature. Still, I didn't want to discourage someone enthusiastic about the project. I especially didn't want to discourage anyone willing to give money to an open-source project.

Based on the time required to implement and support the feature, it's less than I would charge for regular work at an hourly rate, but it was certainly appreciated.

When everyone's working together for the collective good

"Why do you care? You're leaving at the end of the week."

I've been reading, the excellent, Turn the Ship Around by L. David Marquet.

It's made me reflect on two work-related scenarios:

The first is where the above quote comes from. It was after the weekly developer-team meeting and two days before I left the company. In the meeting, I advocated for a change to a process that I thought would improve the time and effort required. I wouldn't be around to see the benefit, but everyone else would. That a colleague asked me why I cared when I'd be leaving confirmed that I wasn't a good fit for the company I was soon to leave. I wonder how many people in this world are like this colleague. I hope it's only a few. I fear it's a majority.

The second scenario is more current. I'm being passively-aggressively encouraged to step away from an open-source project I've been contributing to for several years. A change of leadership and priorities (that are no longer public) clash with my desire to understand why decisions are being made and being open about what is happening in an open-source project. Not wanting to stay where I'm not wanted, I'm thinking about where to best focus my time and attention next. But I'm also concerned about what I'm leaving behind. Before I go, I want to ensure I'm leaving it in the best possible state, and that means continuing to strive for improvements. I'm still trying to work out how to do this in the best possible way and am open to suggestions.

I want to make things better. In addition to the products I work on, I desire to make the places I work, the projects I work on, and the processes I use to make things better.

Is this misguided? I hope not.

Is this all a case of me caring too much? If so, how much is too much?

What's it like when everyone on the team is working to make not just a great product but improve the process as well? - If you have experience of this, I'd love to hear about it.

Is your organization looking for an experienced .NET & Windows developer who isn't afraid to speak up and improve processes?  I might be a good fit. I'd love to hear from you too. 😉

Open-source is like politics - show up to make a difference

Open source is like politics.
But, probably not in the way you're thinking. Not politics in a negative sense as if it's all about power, domination, and control.

Photo by Element5 Digital on Unsplash

I think open source is like politics in that many people think about it in the same way as they do the politics of local government.

What do these refer to?

• Generally, people think it's a good idea.
• Typically, people take what they can from it and don't give back beyond what's required/forced.
• People think about getting involved a lot more than they do.
• Lots of people have [strong] opinions but don't act on them.
• A few people contribute a lot (of time and effort).
• People who contribute are rarely rewarded or compensated well.
• When a person is directly affected, they may show up wanting action on the issue that affects them. But, their desire to look at (or consider) anything else is small, and their enthusiasm is short-lived.

Were those comments about local government or open-source software?

I hope you can see they apply to both.

I think the similarity also extends to how to make a difference in each.

Who are the people who make a difference in local politics?

They're the people who turn up. Repeatedly, regularly, and when it's not always in their immediate interest. They do things to help the community.

Four things to do:

1. Show commitment. Turn up regularly. (Not just to be seen but also because it's often the only way of knowing what's going on.)
2. Work for everyone's benefit. Do things that help others, not just you.
3. Share your knowledge. Not to show off but to help others.
4. Think long term. Not only immediate benefits.

Doing the above will build trust and a reputation that will support your big ideas down the line.

Yes, large organizations and people with a lot of money, influence, or celebrity can come in and make a big difference in a short amount of time. I'm assuming you're not one of them (I'm not either), and so you have to do what you can with what you've got.

Does this really work?

There are some examples from WinUI where community members (people) have suggested new controls and an alternate syntax that were then implemented by the team.

But what about something bigger?

The most prominent example I have of influencing a Windows-related open-source project is adding support for Visual Basic(!) in Windows Template Studio. This was a big deal as it was a significant change and would be something with long-term consequences.

This is something that I (as a non-Microsoft employee) persuaded Microsoft to add.

• I did this for a project in which I had built a reputation for regularly participating.
• I'd previously displayed knowledge so that the project leads valued my opinion.
• I backed up my suggestion with data. (Not data I had but data I knew they could get access to and assumed would support my proposal.)
• I suggested something that aligned with the larger goals of the project and organization.
• I suggested something that wasn't in my immediate interests but would help underserved members of the community.
• I showed how I could help make the change easy by volunteering to help with the work.

Only big changes?

Let me be clear, contributing to open-source isn't only about big changes!

Every little helps! It's not just true of supermarkets. All the small things we do add up. 

One of the great benefits and advantages of open-source software is that it can be built on many people's wisdom, knowledge, skills, and contributions. Not everyone can make large contributions (in size or number) to every project. But, all contributions help, regardless of size, when they work to build better software for everyone.

Improving documentation, giving feedback on a spec or proposed feature, adding a real-world example, and sharing details of a project. These can all be just as valuable as writing code.  

There are projects where I've only ever made small changes. Yes, even only fixing typos. I know these don't make a massive difference but they do help those who come after me and they do make a difference.

Start small and then work up. Or don't. Staying small is good too.

I drafted the first version of this post in early February.

As part of the WinUI Community Call on 17th February  2021, they included a section on "Maximizing Your Influence on WinUI." (Watch that section on YouTube)

There was lots of good advice in that call/video, and I think it complements what I've said above.

If you don't want to watch a 15-minute video, here are some screen grabs of the slides shown, or check out this document where they summarize the key points.

WinUI isn't a project where you can easily come in and make big changes, or expect dramatic changes in direction. But you can help make a difference, not only to the project but also to the lives of the developers and the people who use the software they create.

My impact on the spec process is the most significant change I've made there, but I'm not disheartened. I know I've made a difference that helps others and I hope that my contributions, suggestions, feedback, and support will continue to have a broader impact in the future.

Keep showing up.

Let's make a difference together.

It's sad and happy to deprecate something that's no longer needed.

A couple of years ago, I built a tool called UWP Design-Time Data (GitHub | NuGet)

It attempted to provide some functionality that was available in Xamarin.Forms (XF) but not in UWP.
I saw someone from Microsoft show the functionality available to XF developers and immediately wondered two things? When will that be available to UWP? And, how can I recreate that until then? 

Based on the limited XAML extensibility of Visual Studio, I did the best I could. It wasn't perfect, but it was better than nothing.

Mine was never meant to be a permanent solution.
I always expected and hoped for it to go away. The last time I gave a conference talk about XAML tooling (in Feb 2020), I even talked about mine being a temporary solution.

Version 16.7 of Visual Studio (actually released in the middle of last year) added this as part of several other XAML-related improvements.

Today I finally got round to updating the GitHub repo and Nuget listings.

I'm not going to take them down, but they're essentially deprecated, and I don't ever expect to update them again.

It's sad to think that this is the end of this project.
All the time and effort I spent on this has no future value.
Hopefully, at least some of what I learned in the creation and support of this will be useful in the future.
But, it's good to know that this small but useful functionality is now available to all VS users, not just those who hear about and install my extension.
It's also good that to think that I was able to help some people for a while.

Today is a time to celebrate what was and look again at what comes next. 🥂

Never just "should"!

 TLDR: never use "should" without explaining why.

Photo by Brett Sayles on Pexels

How many times today have you used the word "should"?

"You should do X."

"They should do Y."

"It shouldn't be like that."

Or any variation on that theme?

"should just" is even worse.

"You should just do X."

This use of "just" implies it's simple or easy to do. It implies little effort will be needed. But, that isn't always the case.

What may be simple for you may not be for someone else. 

What may seem simple from the outside belies what may actually be required to make it happen.

Avoid saying "just" when it implies simplicity unless it's something you're doing and already know how to do.

"Should" is more complicated.

You may be familiar with the MoSCoW method of prioritization. I was taught this at university and have never liked how vague and open to interpretation the categories still are. I've been in far too many meetings throughout my career that have come down to different understandings of what needs to be delivered. In these situations, "should" is either considered to mean:

• It would be nice if this was included, but it isn't strictly necessary. 
• It's used to indicate or identify something that can be deferred until another time.
• Or it's understood to mean something that can only be left out without a VERY good reason. 

"Should" can cause confusion.

Or, maybe you're used to seeing SHOULD in documents where it takes the definition from RFC2119.

. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

This is the crux of my issue. It admits that there are one or more reasons why something should or shouldn't be done.

If you say that "something should be done," why should it be done?

Because of your personal preference?

Because of a contractual reason?

Because of knock-on effects and dependencies or consequences elsewhere?

Without knowing the reason(s) that something "should" be done, we're forced to guess.

If the person saying "we should do X" has the ultimate authority to make decisions, then knowing why has less importance. It might be helpful, useful, or empowering to understand why, but it's not essential. 

In this scenario, a different word is more appropriate. "Please do X." is more specific and more helpful. Even if it's a bit abrupt, it's better than adding unnecessary and potentially confusing words.

If not direct instruction, knowing why is essential. If an opinion, we may be free to ignore it. If a contractual requirement, then we need to know to make sure it happens. If a pressing priority, time-sensitive or will have considerable consequences if not know and acted upon, then we need to know.

It might not be as severe as "you should stop that small child walking into traffic," but explaining why something "should" be done is considerate.

"You should do X" is rude.

"If you do X, it will help me..." or "if X is done first, it will unblock this other work" or "we need to make sure that we do X" are respectful and collaborative. 

Words matter.

You must be insane to be a software developer

"The definition of insanity is doing the same thing over and over again and expecting a different result." - Probably not Albert Einstein.

When debugging, I repeat myself frequently. Doing the same thing over and over again and hoping for a different result.

There are times I wish I had alternatives, but I know no other way, and so I rerun the code. Each time hoping that something will be different.

Rarely it is.

But it's those rare occasions that make this approach acceptable, if not necessary.

Note. I'm not talking about Heisenbugs. They're a separate, additional thing.

Sometimes repetition is the only option. An issue is observed or reported as only happening "some of the time." In such scenarios, the only available option is to run the code or perform an action to see when the bad thing occurs. Then try and identify what the difference was when it happened. 

This is important because, without consistent reproducibility of an issue, it's impossible to be 100% confident of an applied fix.

I know many developers and organizations who dismiss reports of occasional issues. If the problem doesn't happen all the time, so their thinking goes, it must not be with their software. Or they assume that the responsibility to fully identify the cause of the bug is not theirs. Or, they think their time would be wasted trying to reproduce such bugs consistently.

This comes down to perspective and priority.

Is the developer tasked only with writing the code? Or is the code a means to an end?  

I think the goal of writing code is to deliver value. I don't see any value being delivered by dismissing a bug report because it's not consistently reproducible. Instead, I see this as a challenge.

I assume that the person reporting the problem has given all the information they can. Now the challenge is for me to investigate the situation and find the solution. I'm a detective. 🔍

Being a bug detective might (and often does) mean repeating tasks to see when there is an inconsistent response and then trying to work out the cause. Such problems usually come down to one of four things.

• It's time (or date) dependent.
• It's machine/OS/configuration dependent.
• It's a race condition.
• It's dependent on the number of times the function is executed.

That time it failed, and the time before it worked even though the code hasn't changed. What else has changed? And how can I test that?

Note. I know there are obscure edge case bugs that it's not the best use of anybody's time to address. Let's assume that here I'm talking about bugs that the business deems worth spending time/money/effort fixing.

I wonder if there are better ways to investigate such bugs.

I wonder if there are tools to help with this. (I've found references to a few things that no longer exist but nothing current. 😢)

I will frequently run unaltered code and hope for a different result. Surely I'm not the only one...