As a developer who started out in a Microsoft house - and has always worked in one - I’ve always used their tools. Visual Studio and Visual Studio Code. I never expected that I’d now have made the big switch over to JetBrains.
The Microsoft House I Grew Up In
I started out in the NHS, a Microsoft house, using Visual Studio for my development work. I was comfortable with it, and it had all the features I needed. When Visual Studio Code came out, we started playing around with that too. I used it a lot for front end work, and anything more configuration related, including IaC. Visual Studio started to feel clunky, especially for something as simple as a bug fix. I ended up moving to VS Code for everything, all of my development work, and it was great. Whilst I did end up having to use the terminal a lot more, along with quite a few extensions, it was easier. I didn’t have the best of laptops, maybe this was a factor here too!
This Wasn’t a Rage Quit
Towards the end of my time in the NHS, I had stepped away from day to day dev, it was all config and IaC work, so VS Code was fine. Then I moved roles and joined where I am now as an Azure Solutions Architect - I didn’t expect to be writing loads of code… Things changed, I ended up jumping into a project to help out and writing a LOT of code. I jumped onto Company Portal and downloaded Visual Studio, and I was back to using it. I started getting fed up pretty quickly, slow and clunky. Talking to another dev I commented I was going to go back to VS Code, but with some slight bullying, I downloaded a Rider trial…
The JetBrains Moment
I was full on developing on a Blazor App and using Rider every day, it was great. Lighter, faster and overall a better experience. I was hooked, within a few days I had bought the dotUltimate License, and I was flying. Rider just felt more intuitive in every way. I had some initial hiccups with it, mostly cause by also using Vim. The Vim plugin, combined with keyboard shortcuts suggested by a friend, caused a few collisions. But the IDE just handled it, a little toast icon to ask which it should be, Vim or IDE - great! The tools built in just made things so much easier. The one that really helped was the refactor tools, especially helpful when we were working on the Blazor app that involved a partial rebuild but retaining certain elements from the original solution. They helped with moving the content, renaming files and classes, and just generally made the process smoother.
Within a month or so, I’d moved all my work to JetBrains IDEs, including IaC and DevOps work. Then I started using WebStorm for this blog, just using the non-commercial license to start with. Pretty soon after my partner asked for some help with her web side hustle - time to upgrade the license.
Now I have the full product pack, using as many as I need. Rider for .NET work, WebStorm for front end and blog work, and GoLand for learning some Go. On the topic of learning, the built-in academy courses are fantastic. They don’t have them for .Net but having tried the one for Go, I could not recommend these anymore.
Living in JetBrains Day to Day and What I Miss
It’s always a possibility that you start using something, and it just doesn’t stick, but having been using JetBrains for around 6 months now, I can say that their tools have become my go to for everything I am doing. You always get used to something, and they can take time to become second nature, but even just the easier navigation and refactoring has made it worth it.
The only thing I haven’t found as good yet, was the Bicep integration for IaC work. However, speaking to the team at JetBrains during an event, this has come a long way and I need to try it again.
Whilst I’m not missing anything specific, it can be a bit of a pain now working with others as not everyone at work has made the switch. Things like pair programming on a live session is now a bit limited, or trying to help someone onboard, but they are using different tooling.
Tooling Should Get Out of The Way
Maybe this sounds a bit cliché, but it’s true. The tools that you use should get out of the way and let you do your best work. For me, the switch has helped with that. Doesn’t mean it will for everyone, and I’m certainly not going to judge anyway for sticking with Visual Studio, at least not much anyway! didn’t switch because Visual Studio is bad — it just wasn’t working as well for me anymore.