The biggest thing is the UI being completely different. I did use VS Code before, but only for my own projects, not stuff for work. So I did know how to use VS Code, but still it’s a major mental adjustment with everything being in a different place, features and shortcuts working differently etc.

I really missed to Solution Explorer, which is probably my most used tool during work. But thankfully there is an excellent plugin which provides a Solution Explorer in VS Code. It’s a bit different from what I’m used to but it works just fine.

Normally for casual profiling I’d use VS builtin tools. Only switching to something like DotMemory when really diving into optimization. This seems to be missing from VS Code. Probably there’s a plugin to fix that, but I want to keep the number of plugins to a minimum to prevent issues of plugins not being updated or having compatibility issues as much as possible. So now I switched to a different work flow for this to use tools like DotMemory sooner instead of the builtin stuff from VS.

Resharper isn’t available for VS Code yet, but I don’t mind it. Some of my colleagues use it, but I prefer to do everything myself anyways and not use automated tools for code.

I miss the Nuget package manager. Everything can be done using the terminal, both in VS and VS Code, which works the same. But the UI provided by the manager is so nice, it shows all the info you need, let’s you do almost anything with two clicks. I’ve checked out some plugins which are supposed to help with this, but have found none as good as the VS package manager. I’m proficient enough with the terminal it doesn’t really matter, but I still miss the manager and find myself checking different sources manually which used to be a lot more efficient. So I’ve taken an efficiency hit here, but I still can get the job done.

Having everything done in the terminal panel takes some getting used to, where VS often launches different windows to get different kind of outputs. This is just something to get used to and could probably be changed in the settings, but I think it’s fine.

In VS the project is launched as a separate process and then VS attaches itself to the process for debug and inspection purposes. In VS Code it’s a subprocess of the main editor process. This has some implications using third party tools for profiling for example. But I haven’t noticed anything going wrong. I think the way VS does it is better, but it’s probably fine? In theory an application could crash the whole VS Code process. But my code never crashes so I should be fine, right?

Running and debugging is different but fine, with different profiles and debugging flags being managed from the UI and working perfectly. Publishing however is done only using the terminal, not the UI. Everything I need is available, but it took some figuring out how I need to do stuff using the terminal with regards to publishing. I’ve created a page on Confluence for myself with all the different stuff, which flags etc. It took some time but I think I’ve got everything figured out.

For version management we already used a third party tool, so luckily no changes there. I have had to set some new ignores, but other than that no changes.

Creating new projects is something I haven’t figured out how to do. For work I only ever work in existing projects that have been around for ages. I don’t know how easy it would be to create something new with all the required files and parameters so my colleagues can also use it. The other day I wanted to quickly check something in an empty project and I had to reach for VS again (for shame). I need to put in some time figuring this out in VS. It’s probably not complicated, but as I said I wanted to check something quickly so I didn’t have the time.

There are probably a thousand little things I have changed or have to get used to. But these are the main ones.

I hope you take this in good humor and at least consider a TUI for your next project.

Absolutely. I see what you did there… 😉

But seriously, thank you for your response!

I think your comment about GUIs being better at displaying the current state and context was very insightful. Most CLI work I do is generally about composing a pipeline and shoving some sort of data through it. As a class of work, that’s a common task, but certainly not the only thing I do with my PC.

Multistage operations like, say, Bluetooth pairing I definitely prefer to use the GUI for. I think it is partially because of the state tracking inherent in the process.

Thanks again!

Thank you for responding! I really liked this bit

with a (decently designed) UI, you merely have to remember the path you took to get to wherever you want to go, what buttons to press, what mouse movements to execute.

I think that’s very insightful. I certainly have developed muscle-memory for many of my most-frequent commands in the CLI or editor of choice.

I agree about Visual Studio as a preference. I’ve used (or at least tried) dozens of IDE setups down the years from vi/emacs to JetBrains/VS to more esoteric things like Code Bubbles. I’ve found my personal happy place but I’d never tell someone else their way of working was wrong.

(Except for emacs devs. (Excepting again evil-mode emacs devs - who are merely confused and are approaching the light.)) ;)