To date I’ve primarily been a “.NET developer”; which is to say that most of the code I’ve written for work or for fun has been C# or VB .NET running in a Windows environment. I’ve often wanted to work with other languages or platforms, but have stuck to what I know because it’s paid the bills and I’ve always been able to find interesting things to work on in the .NET space. I have dabbled in some other stuff, but have typically found it difficult to overcome the inertia that’s kept me tied to .NET on Windows. I’ve recently come to realize that a lot of this inertia is rooted in the in the sheer number of ancillary things that you tend to need to learn when you want to experiment with a new language or platform.
A High Barrier To Entry
For example, if I wanted to learn about writing iOS apps in Objective-C I’d probably need to pick up OS X, XCode, Cocoa, and Objective-C. Basically, I’d need to pick up an entirely new technology stack to work this way and that is a very daunting proposition to me. If I wanted to pick up, say, Ruby, I’d be in slightly better shape because Ruby already runs on Windows, but I’d still need to pick an editor or IDE to work with and learn its quirks to find a good “code-test-run-repeat” cadence. I’m certain that I could get it all figured out if I really had to (e.g. if my job required it), but in the limited spare time I have for “software-related side projects” (which, in addition to learning new languages, includes blogging, contributing to open source, reading technical books, etc.) I simply can’t find enough uninterrupted time to wrap my head around more than one of those things at a time. To me it’s very suiting that the word “experiment” often gets used when referring to learning something new because, just like any experiment, there can be many variables at play: operating system, editor/IDE, framework, environment, etc. I’m not opposed to learning about new operating systems, frameworks, or IDEs, but I’ve found that I’m far more likely to be successful at learning something new if I can limit those variables and try to learn one new thing at a time.
Visual Studio is a Crutch
Visual Studio is a crutch. Visual Studio is a terribly large and sometimes awkward crutch. Most of the time it works and lets me write, compile, run, and debug code with great ease, but sometimes it slips and lets me fall on the pavement. Nonetheless, it’s “the devil I know”, and I do like using it for the most part. I’ve been very excited recently by the recent releases of things like Python Tools for Visual Studio and Node.js Tools for Visual Studio. Being able to use Visual Studio to play around with Python or Node.js makes them a lot more approachable for me and lets me focus on on learning the ins and outs of those languages and platforms themselves in an IDE and operating environment that I’m already familiar with. After downloading the Python tools a little while back I finally sat down and hacked out a short Python script that did more than just “hello world” and found it immensely satisfying. Being able to pick up a new language and actually build something that is even the slightest bit useful to you is a great catalyst to continuing to work with that language and keeping it mind for projects down the road. Are are probably better editors or IDEs to use with Python and if I were to embark on a Python project of any significant size I’d probably bite the bullet and learn how write Python the “right way”, but without being able to work with it in a familiar environment I would have never done anything useful with it at all.
My experiment with Python in Visual Studio went so well that I’m dabbling a bit with Node.js in Visual Studio as well. I’ve been interested in the Node.js project for awhile now, and have even put together the obligatory “hello world” app, but haven’t really been able to go much further with it yet. I’m hoping that the Visual Studio tools for Node.js work as advertised and let me get my feet wet with that platform.