Why we don’t hire .NET programmers

Tuesday midnight edit: After >500 comments, >1000 tweets, and >1000 Facebook likes, I’m closing comments on this thread so we can all get back to work.  The very last comment takes the cake, however, and is a fitting close.  Thanks ez, whoever you are!

As you might know, we’re hiring the best programmers in the world.  Sure, everyone says that.  But my coders will beat up your coders, any day of the week.  For example, Mich is barely 5 foot tall, but is a competitive fencer.  Witold is a 6’3″ former professional hockey player.  Nate practices knife fighting for fun.  And they’re pretty decent programmers, too.

But finding such people is more than a full time job.  Indeed, I spend about half my time on it, while Lisa spends about all hers.  And on top of that we have an army of recruiters out scouring the globe, leaving no resume unturned.  Taken all together, this creates a lot of resumes.  So many that we don’t look at them, because resumes — let’s be honest — are totally worthless.  Rather, we pay all our attention to a few key questions we ask every candidate, each aiming at uncovering a single key point: is this someone we really want to work with?

See, experience is cheap.  All it takes is time.  Skill is harder, but really only requires hard work — a lot of people can get that.  But attitude.  You either have it, or you don’t.  The right sort of person is so passionate about coding, they can’t be stopped from doing it.  They typically started before high school — sometimes before middle school — and never looked back.  They write everything from assembly to jQuery, on PCs to mobile phones, doing hard core computer graphics to high level social networking.  They’ve tried everything.

Everything, that is, but .NET.

Now let me clarify — .NET is a dandy language.  It’s modern, it’s fancy, it’s got all the bells and whistles.  And if you’re doing Windows Mobile 7 apps (which the stats suggest you aren’t), it’s your only choice.  But choosing .NET is a choice, and whenever anybody does it, I can’t help but ask “why?”

Don’t get me wrong: .NET on your resume isn’t an instant showstopper.  But it will definitely raise questions during the phone screen, for reasons that are best explained by simile:

Programming with .NET is like cooking in a McDonalds kitchen.  It is full of amazing tools that automate absolutely everything.  Just press the right button and follow the beeping lights, and you can churn out flawless 1.6 oz burgers faster than anybody else on the planet.

However, if you need to make a 1.7 oz burger, you simply can’t.  There’s no button for it.  The patties are pre-formed in the wrong size.  They start out frozen so they can’t be smushed up and reformed, and the thawing machine is so tightly integrated with the cooking machine that there’s no way to intercept it between the two.  A McDonalds kitchen makes exactly what’s on the McDonalds menu — and does so in an absolutely foolproof fashion.  But it can’t go off the menu, and any attempt to bend the machine to your will just breaks it such that it needs to be sent back to the factory for repairs.

Instead, we look for a very different sort of person.  The sort of person who grew up cooking squirrels over a campfire with sharpened sticks — squirrels they caught and skinned while scavenging in the deep forests for survival.  We don’t want a short order chef, we want a Lord of the Flies, carried by wolves into civilization and raised in a French kitchen full of copper-bottomed pots and fresh-picked herbs.  We need people who can not only cook burgers, but cook anything, from scratch.

See, Microsoft very intentionally (and very successfully) created .NET to be as different as possible from everything else out there, keeping the programmer far away from the details such that they’re wholly and utterly dependent on Microsoft’s truly amazing suite of programming tools to do all the thinking for them.  Microsoft started down this path when they were the only game in town, explicitly to maintain their monopoly by making it as hard as possible to either port Windows apps to non-Windows platforms, or to even conceive of how to do it in the first place.

This decision — or this mandate for incompatibility, perhaps — has produced countless ramifications.  Small things, like using backslashes in file paths rather than forward slashes like any dignified OS., or using a left-handed coordinate system with DirectX instead of right-handed as was used since the dawn of computer graphics.  Big things, like obscuring the networking stack under so many countless layers of abstraction that it’s virtually impossible to even imagine what bytes are actually going over the wire.  And a thousand other things in between: programming tools that generate a dozen complex files before you even write your first line of code, expensive servers that force a remote GUI terminal on you to do essentially anything despite a few keystrokes being perfectly adequate for everybody else,  a programming culture almost allergic to open source licensing.  The list goes on and on.

None of this makes you a “bad programmer”.  All these differences are perfectly irrelevant if you just want to make 1.6 oz burgers as fast as possible, and commit the rest of your career to an endless series of McDonalds menus.  But every day spent in that kitchen is a day NOT spent in a real kitchen, learning how to cook real food, and write real code.

Even worse, every day spent learning a Microsoft kitchen takes TWO days to unlearn, meaning once you get a reasonable way down the .NET career path, there is almost no going back.  You become so steeped in tools and techniques that have absolutely no relevance outside of .NET that you are actually less valuable to a startup than had you just taken a long nap.

So what’s the moral of this whole story?  Two things:

1. If you ever want to work in a startup, avoid .NET.  It does you no favors.
2. If you are a startup looking to hire really excellent people, take notice of .NET on a resume, and ask why it’s there.