.NET, the career killer? Get real.

[This one is going to be seriously uninteresting to the non-programmers, but it attempts to be a helpful opinion about some misperceptions in the programming community.]

So wiglaf_aaronm brought to my attention last night the current tempest in a teapot: Expensify's little rant on why they don't hire .NET programmers. It is sufficiently full of nonsense that a corrective seems appropriate.

So let's talk a bit about environments. The software field is prone to religious wars, and the JVM-vs-CLR one is among the stupidest. Lest anyone peg me as a zealot on either side here, let me lay out my credentials.

On the one side, I was one of Java's earliest adopters: back in the Netscape/IE 3 days, when Java was new and shiny, I wrote what might have been the most sophisticated applet in the world at the time. (A locally-installing, auto-updating, multimedia, children's-educational MUD client written for the DoD. DARPA contracts produce the weirdest jobs.) I cut my OO eyeteeth on Java, to enough of a degree that learning C++ afterwards was kind of painful. When I ran my own garage startup a few years ago, the server was originally written in Java; when that became too annoying (I will admit, I consider Java the language to be behind the times), I stayed on the JVM but switched to Scala, the current Best Language In the World.

OTOH, I've spent the bulk of the past 10 years working in .NET. I taught myself C# for kicks during the nuclear winter of 2002 (my only period of real unemployment); that led me to working mostly in that for five years with Applied Messaging / Convoq / Zingdom, and thence here at Memento for the past couple of years.

So let's be clear: I know both sides of the fence *quite* well, and have worked in lots of languages, for a variety of projects, in both environments. And my summary is that anyone who gets deeply attached to one or the other as far better for development flatly doesn't know what they're talking about.

Going into some of the problems with the linked post:

• I realized that he really had no idea what he was talking about when I got to, ".NET is a dandy language." In case anybody else is confused, .NET isn't a language, any more than the JVM is: it's an environment comprising a virtual machine, a pretty disparate family of compatible languages, and an enormous collection of libraries. In fact, while the details vary a bit, from the thousand-foot view it looks exactly like the JVM environment. It's just parallel evolution.


• "Programming with .NET is like cooking in a McDonalds kitchen." This bit mostly confirms the above. In fact, programming in the .NET languages is so much like programming in the JVM languages as to make no difference. Sure, if all you're doing is programming in ASP.NET and VB, it hides all the interesting details -- just like programming in Rails or PHP does. There are lots of ecosystems, and you choose to program at the level that makes sense for your needs. Moreover, choosing to go with a low-level language when all you need for the problem at hand is a high-level one is just plain dumb, especially from a company POV: it winds up introducing more bugs, wastes programmer time, and makes the system less maintainable. Mind, I *prefer* to program in a more powerful system, but that's because I like the juicy problems -- when I'm building a complex and novel app for a million simultaneous users, I'm going to choose a powerful language. But my comic book database at home is just written in Rails; if I was doing it on .NET, I'd do it in Razor. Anything fancier than that is just wasting my time.


• "Microsoft very intentionally (and very successfully) created .NET to be as different as possible from everything else out there" This shows a surprisingly obtuse misunderstanding of the history. The truth is quite the opposite: most of the .NET environment is very, very much *like* everything else out there. Microsoft deliberately chose to make it *separate* so that once you start building your app in .NET, it turns out to be dumb to use anything non-.NET for it, but "different"? Get real. C# is simply a version of Java that's done a better job of keeping up with the times. F# is mostly a port of OCaml. .NET itself may be separate libraries from the JVM's, but the concepts tend to be very, very similar, and most interesting third-party libraries have near-identical versions on both sides of the fence.


• Oh, and the point of the whole thing? "If you ever want to work in a startup, avoid .NET. It does you no favors." Seriously, dude, both of my last two jobs, as an Architect at solid startups, I got *because* of my C# skills. While it's true that garage startups tend to avoid .NET because of the cost, ones that are well-funded from the beginning tend to love it. In particular, business-oriented startups -- often the ones that have the best odds of profitability, since they tend to have real business plans -- tend to be bullish on Microsoft. So it's true that .NET skills won't help you starve in a garret, but from a career POV it can really help you land a position with a startup whose options have a good chance of paying off. (And seriously, if you have the mind for it, learn both sides of the fence. What *is* foolish is deliberately limiting your options.)

Most importantly, the notion that learning on the .NET side is a career-killer is just arrant nonsense. The reality is that, while the fine details are different, the broad strokes of the .NET environment and the JVM ones are so similar that the skills are all trivially transportable. For purposes of hiring, I consider Java and C# skills to be largely interchangeable. Similarly, if I was looking for someone to program OCaml or Haskell or Scala, I'd consider F# experience to be directly applicable. And if I was just looking for lower-level Web programmers, ASP.NET skills port fairly smoothly to JSP or any other templating framework.

There *are* good reasons to steer clear of .NET, but they are more political than anything else. One can certainly dislike Microsoft's corporate policies (although by and large, they're mostly pretty ordinary these days). If you're fond of open-source, .NET is a mediocre option, although not as bad as it once was. If you're a small startup, MS can be an expensive choice, especially in your early days.

(ETA: I should underline this last. While .NET isn't nearly as different as the original post makes it sound, and while it does have hooks that allow you to work with most external systems, this *is* Microsoft we're talking about. The ecosystem is designed to always make it easier and more powerful to pick the MS option instead of the non-MS one whenever you're presented with a choice. So don't fool yourself: if your company starts sipping the Microsoft Kool-Aid, you're probably going to wind up drinking the whole pitcher. It's a perfectly good choice, but it *is* a choice, and the upfront costs are much high in general than those on the JVM infrastructure. Whether the long-term costs are higher is a whole 'nother argument unto itself, that I don't care to wade into -- there are too many dueling studies for me to pay much attention.)

But seriously: if you're making a career in programming, I recommend just ignoring the religious zealots on both sides of this idiotic war. The truth is that both .NET and the JVM are fine environments, with good language options and rich libraries, and the skills you learn on one side apply quite directly to the other. (And if you're on the business side, for heaven's sake don't pay attention to the religious argument: it injects arrant nonsense into what should be cool-headed decisions...)

.NET, the career killer? Get real.

[This one is going to be seriously uninteresting to the non-programmers, but it attempts to be a helpful opinion about some misperceptions in the programming community.]

So wiglaf_aaronm brought to my attention last night the current tempest in a teapot: Expensify's little rant on why they don't hire .NET programmers. It is sufficiently full of nonsense that a corrective seems appropriate.

So let's talk a bit about environments. The software field is prone to religious wars, and the JVM-vs-CLR one is among the stupidest. Lest anyone peg me as a zealot on either side here, let me lay out my credentials.

On the one side, I was one of Java's earliest adopters: back in the Netscape/IE 3 days, when Java was new and shiny, I wrote what might have been the most sophisticated applet in the world at the time. (A locally-installing, auto-updating, multimedia, children's-educational MUD client written for the DoD. DARPA contracts produce the weirdest jobs.) I cut my OO eyeteeth on Java, to enough of a degree that learning C++ afterwards was kind of painful. When I ran my own garage startup a few years ago, the server was originally written in Java; when that became too annoying (I will admit, I consider Java the language to be behind the times), I stayed on the JVM but switched to Scala, the current Best Language In the World.

OTOH, I've spent the bulk of the past 10 years working in .NET. I taught myself C# for kicks during the nuclear winter of 2002 (my only period of real unemployment); that led me to working mostly in that for five years with Applied Messaging / Convoq / Zingdom, and thence here at Memento for the past couple of years.

So let's be clear: I know both sides of the fence *quite* well, and have worked in lots of languages, for a variety of projects, in both environments. And my summary is that anyone who gets deeply attached to one or the other as far better for development flatly doesn't know what they're talking about.

Going into some of the problems with the linked post:

• I realized that he really had no idea what he was talking about when I got to, ".NET is a dandy language." In case anybody else is confused, .NET isn't a language, any more than the JVM is: it's an environment comprising a virtual machine, a pretty disparate family of compatible languages, and an enormous collection of libraries. In fact, while the details vary a bit, from the thousand-foot view it looks exactly like the JVM environment. It's just parallel evolution.


• "Programming with .NET is like cooking in a McDonalds kitchen." This bit mostly confirms the above. In fact, programming in the .NET languages is so much like programming in the JVM languages as to make no difference. Sure, if all you're doing is programming in ASP.NET and VB, it hides all the interesting details -- just like programming in Rails or PHP does. There are lots of ecosystems, and you choose to program at the level that makes sense for your needs. Moreover, choosing to go with a low-level language when all you need for the problem at hand is a high-level one is just plain dumb, especially from a company POV: it winds up introducing more bugs, wastes programmer time, and makes the system less maintainable. Mind, I *prefer* to program in a more powerful system, but that's because I like the juicy problems -- when I'm building a complex and novel app for a million simultaneous users, I'm going to choose a powerful language. But my comic book database at home is just written in Rails; if I was doing it on .NET, I'd do it in Razor. Anything fancier than that is just wasting my time.


• "Microsoft very intentionally (and very successfully) created .NET to be as different as possible from everything else out there" This shows a surprisingly obtuse misunderstanding of the history. The truth is quite the opposite: most of the .NET environment is very, very much *like* everything else out there. Microsoft deliberately chose to make it *separate* so that once you start building your app in .NET, it turns out to be dumb to use anything non-.NET for it, but "different"? Get real. C# is simply a version of Java that's done a better job of keeping up with the times. F# is mostly a port of OCaml. .NET itself may be separate libraries from the JVM's, but the concepts tend to be very, very similar, and most interesting third-party libraries have near-identical versions on both sides of the fence.


• Oh, and the point of the whole thing? "If you ever want to work in a startup, avoid .NET. It does you no favors." Seriously, dude, both of my last two jobs, as an Architect at solid startups, I got *because* of my C# skills. While it's true that garage startups tend to avoid .NET because of the cost, ones that are well-funded from the beginning tend to love it. In particular, business-oriented startups -- often the ones that have the best odds of profitability, since they tend to have real business plans -- tend to be bullish on Microsoft. So it's true that .NET skills won't help you starve in a garret, but from a career POV it can really help you land a position with a startup whose options have a good chance of paying off. (And seriously, if you have the mind for it, learn both sides of the fence. What *is* foolish is deliberately limiting your options.)

Most importantly, the notion that learning on the .NET side is a career-killer is just arrant nonsense. The reality is that, while the fine details are different, the broad strokes of the .NET environment and the JVM ones are so similar that the skills are all trivially transportable. For purposes of hiring, I consider Java and C# skills to be largely interchangeable. Similarly, if I was looking for someone to program OCaml or Haskell or Scala, I'd consider F# experience to be directly applicable. And if I was just looking for lower-level Web programmers, ASP.NET skills port fairly smoothly to JSP or any other templating framework.

There *are* good reasons to steer clear of .NET, but they are more political than anything else. One can certainly dislike Microsoft's corporate policies (although by and large, they're mostly pretty ordinary these days). If you're fond of open-source, .NET is a mediocre option, although not as bad as it once was. If you're a small startup, MS can be an expensive choice, especially in your early days.

(ETA: I should underline this last. While .NET isn't nearly as different as the original post makes it sound, and while it does have hooks that allow you to work with most external systems, this *is* Microsoft we're talking about. The ecosystem is designed to always make it easier and more powerful to pick the MS option instead of the non-MS one whenever you're presented with a choice. So don't fool yourself: if your company starts sipping the Microsoft Kool-Aid, you're probably going to wind up drinking the whole pitcher. It's a perfectly good choice, but it *is* a choice, and the upfront costs are much high in general than those on the JVM infrastructure. Whether the long-term costs are higher is a whole 'nother argument unto itself, that I don't care to wade into -- there are too many dueling studies for me to pay much attention.)

But seriously: if you're making a career in programming, I recommend just ignoring the religious zealots on both sides of this idiotic war. The truth is that both .NET and the JVM are fine environments, with good language options and rich libraries, and the skills you learn on one side apply quite directly to the other. (And if you're on the business side, for heaven's sake don't pay attention to the religious argument: it injects arrant nonsense into what should be cool-headed decisions...)

Trees are my friend, even if they're just logical ones

When confronted with a monumental project, there's nothing quite like breaking it down into as many medium-level problems as you can, then sketching out the dependencies between them. The result still looks huge, but suddenly it looks *tractable*, with a lot more clarity of where the critical path is. I've had this huge bundle in my head for weeks, but only when I sit down and list each task and its preconditions does it become crystal-clear where we hit the bottleneck in the process, after which we can parallelize the heck out of the rest of development...

Trees are my friend, even if they're just logical ones

When confronted with a monumental project, there's nothing quite like breaking it down into as many medium-level problems as you can, then sketching out the dependencies between them. The result still looks huge, but suddenly it looks *tractable*, with a lot more clarity of where the critical path is. I've had this huge bundle in my head for weeks, but only when I sit down and list each task and its preconditions does it become crystal-clear where we hit the bottleneck in the process, after which we can parallelize the heck out of the rest of development...

Programming in Scala (kind of) available online

For those curious about my frequent rhapsodies about Scala, you may want to check out the bible of the subject, which has just been published online for free.

There is, of course, a gotcha: this is the first edition of the book, not the second, so it doesn't talk about the fairly major improvements in the current 2.8 release of the language, much less the soon-to-be-released 2.9. But it's still 95% accurate and covers 90% of the interesting topics, so it's a convenient way to check out all of the ins and outs of the language for free...

Programming in Scala (kind of) available online

For those curious about my frequent rhapsodies about Scala, you may want to check out the bible of the subject, which has just been published online for free.

There is, of course, a gotcha: this is the first edition of the book, not the second, so it doesn't talk about the fairly major improvements in the current 2.8 release of the language, much less the soon-to-be-released 2.9. But it's still 95% accurate and covers 90% of the interesting topics, so it's a convenient way to check out all of the ins and outs of the language for free...