I was reading scrollback on irc this morning, where a number of my students were discussing the unit tests for the webvtt project we're doing this term. The main issue was that Visual Studio didn't seem to provide the equivalent of our autotools build system's ``make check`', that is, it can't run all our tests and report back. Various solutions were discussed, some sensible, some less so.
Our autotools build actually works in Windows; you can ``make check`' to your heart's content. The real issue here is, in my opinion, an unhelpful (I would go so far as to say 'harmful') reliance on Visual Studio. I make this bold claim because I was once in the same position. I can remember very well being wholly, and completely dependent on Visual Studio for just about everything I did as a programmer. And why not? Visual Studio is an amazing tool, right?
The longer I've programmed, the more I've come to see it as a trap. Not because it costs money, or because Microsoft makes it, or because it isn't open source. I'm writing this blog post on a Mac, so I've already made my peace with pragmatism over Free as in Open. No, the trap of Visual Studio is being able to do only what Visual Studio can do, which seems like a lot, until you need to start doing things it can't do, or worse, things it doesn't want you to do.
I spend much of my time training new developers, and what I'm going to say will seem to run counter to the teaching of my colleagues. I want to be clear that I think you should learn how to use Visual Studio, if for no other reason than to learn how its debugger works. While you're learning and using that debugger, understand what's happening; understand that as a programmer you have a set of needs, and debugger is one of the main ones. Now spend some time with Visual Studio's editor. It's pretty good. While you're doing this, understand that you're using an editor, that this is another of the fundamental needs you'll have for your entire career.
Take an approach to using Visual Studio that makes you aware of its constituent parts, and less as a monolithic whole. Why should you do this? It's important to understand that you need various kinds of development tools, from editors to debuggers to compilers to linkers (quick, what is the name of the compiler and linker on Windows?) to static analysis tools of all kinds, and that Visual Studio provides some of these. It does not provide them all. Not by a long shot.
When this isn't done, and Visual Studio is viewed as a whole, as a development platform, as the way I write code, a number of immediate consequences follow. First, the only kinds of programs you'll write are those which Visual Studio can produce. In essence, your platform isn't even Windows any more, it is Visual Studio. Want to work on OS X? What about Linux? What about embedded systems? What about gaming consoles? The scope and scale of your work as a developer becomes the answer to the question, "Does it run Visual Studio?"
If, on the other hand, you start to understand Visual Studio as a set of tools, and more, a set of replaceable tools instead of your go-to-dev-platform, interesting possibilities arise. You might notice, for example, that you're writing code in C or C++, and this code is being compiled by cl.exe. What if you switched compilers? What if you used clang or gcc? What if you tried a different editor, one that also worked on other platforms, one that supported languages Visual Studio doesn't seem to know about?
A number of things happen in that moment. Suddenly, and it is like opening a dam, a flood of new tools, languages, and platforms comes into scope. Maybe you've avoided trying some new language or tool that others are raving about, putting it off because it didn't seem to fit into the world-view that Visual Studio provided. Don't tell me you haven't because I know it to be true--I used to do this all the time. If your choice of tooling, platform, language, etc. begins with a question about Visual Studio, you are missing out already.
And what am I advocating instead of Visual Studio? Should you do what I do? Probably not. I use the command line and emacs for everything, and there are probably better options for someone starting today. Whatever you pick, be aware of the limitations your choices impose on you. I still use emacs because it's important to me to be able to SSH into remote boxes and work identically to how I work locally. I also choose to only work with tools that work on Windows, Mac, and Linux, so I can be productive everywhere. If I was starting today, I'd probably use Sublime.
It doesn't matter what you use, and the best programmers I know change their tools and platforms all the time, making decisions based on project needs vs. what their old tools can do.
You should use what works until it doesn't, and then move on to other things. Don't be nostalgic. Your life as a programmer will involve constant changes in languages, tools, and platforms, and if the only thing making that decision for you is Visual Studio, you will quickly lose the agility you need to stay relevant in the industry.