CEO Friday: Why we don’t hire .NET programmers

w1z4rd

w1z4rd

Karmic Sangoma
Joined
Jan 17, 2005
Messages
52,146
Reaction score
8,340
Location
127.0.0.1
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:

If you ever want to work in a startup, avoid .NET. It does you no favors.
If you are a startup looking to hire really excellent people, take notice of .NET on a resume, and ask why it’s there.
It might sound harsh, and it is. But sometimes we only have squirrels to eat, and we need them to taste good.
Click to expand...
http://blog.expensify.com/2011/03/25/ceo-friday-why-we-dont-hire-net-programmers/

Theres more info at the link, including responses from emotionally upset .NET devs.
 
Sounds about right... I'm one of the non .NET types. I find that typically people who only start programming in university etc will like the MS way because it's taught there etc. Guys who learn for themselves will go with other languages, typically open source sorts.

Sent from my HTC Desire using Tapatalk
 
I think the biggest thing why most start-ups dont use microsoft is because of pricing... if all MS's stuff was free we see more uptake. I like .net. It allows me to do all my mundane stuff quickly and I can focus on actually giving the business what they need. I've seen too many people struggle with the respective open source technologies and not focus on actually providing a product. Dont get me wrong, I like Java etc too and I will start playing with Cuda soon, but hey when it takes me 3 hours to put a big database form together from inception to deployment whereas for the java guys it takes days, well then I'd rather stick with .net thank you very much.
 
The article is outdated. Was the case 5+ years ago. These days .net and java framework are both huge and the reason why other languages like Ruby are becomming more attractive.
 
Well we started a successful software development company mostly using the .Net platform and we're still going strong 10yrs later, so I really don't think such a dogmatic and rigid opposition to one specific technology is very useful. One of the reasons why we standardized on .Net is that it is much easier to source .Net skills and it's pretty universally supported.

I really think such rigid thinking is dangerous. Sure, if your company is writing embedded software for an industrial process, then you wouldn't be interested in the .Net route, but since 90% of the bespoke software market is for website and business applications, you'd really be making life hard for yourself as a company if you simply ignore an entire platform. If you avoid the mainstream, you run the risk of developing everything on an increasingly obscure platform that will scare away clients and make it very hard for you to find matching skills.

As a corporate client looking for a company to develop software for a project would you be more comfortable with a proposal to develop using box standard .Net or php technologies with SQL/MySQL or would you go with some crowd who only work on some obscure platform because nothing else measures up to their development ideology? Why would you want your bespoke accounting app (or whatever) developed in java when it could be done quickly, cheaply and effectively in .net?
 
garp said:
Well we started a successful software development company mostly using the .Net platform and we're still going strong 10yrs later, so I really don't think such a dogmatic and rigid opposition to one specific technology is very useful. One of the reasons why we standardized on .Net is that it is much easier to source .Net skills and it's pretty universally supported.

I really think such rigid thinking is dangerous. Sure, if your company is writing embedded software for an industrial process, then you wouldn't be interested in the .Net route, but since 90% of the bespoke software market is for website and business applications, you'd really be making life hard for yourself as a company if you simply ignore an entire platform. If you avoid the mainstream, you run the risk of developing everything on an increasingly obscure platform that will scare away clients and make it very hard for you to find matching skills.

As a corporate client looking for a company to develop software for a project would you be more comfortable with a proposal to develop using box standard .Net or php technologies with SQL/MySQL or would you go with some crowd who only work on some obscure platform because nothing else measures up to their development ideology? Why would you want your bespoke accounting app (or whatever) developed in java when it could be done quickly, cheaply and effectively in .net?
Click to expand...

You can't apply .NET to everything, the same way you can't use PHP or jQuery or Classic ASP or Python or Ruby for everything. Several factors dictate which technology/programming platform you're going to go with. People/programmers tend to get stuck into one train of thought when they do get a project (or tender for one).

As an example, several years back I worked for a company that (probably still) uses Classic ASP and JavaScript as their platform. Using AJAX (before the term was even coined FYI) for their interface and a grid system written in JavaScript to leverage off "today's powerful PC's" to render sections of data useful to the end-user looking at it. When it was time for new programmers to join the fray they did. We taught them how the system/concept work. We trained them in our framework we wrote and we asked them to continue adding onto it for our clients.

Then one day a simple problem popped up where the client requested a file be delivered via the web app, but the file will be generated on a different domain. They were stumped. Cross-domain security screwed with their JavaScript calls and they couldn't figure out why. It took them 2 days before I stepped in and went "Why not just use a server-side XMLHTTP call to do that so that it always run on the same domain?" A simple solution to a problem they were struggling with but couldn't see since they only had 1 programming technology in mind they wanted it to work with _ALWAYS_

So when a client approaches me for a project, I go through several questions with them while drawing up the project outline and in there I then decide which is better to go with. I've seen companies force their clients to go with a Windows (or Linux) environment just because their "skills" didn't cover the other plethora of languages/platforms out there. Never to the benefit of the client, but the benefit of the programming house. I give the client what they want regardless of technology/platform/programming required. If it means I do something in Delphi, I will. Of course I will suggest other technologies that might better suit their needs, but it's up to them to decide that at the end of the day and I always love a challenge.
 
Now let me clarify — .NET is a dandy language.
Click to expand...
:wtf:

That statement alone sealed the deal for me. This person is clueless about .Net and is a terrible recruiter. :sick:
 
AcidRaZor said:
You can't apply .NET to everything, the same way you can't use PHP or jQuery or Classic ASP or Python or Ruby for everything. Several factors dictate which technology/programming platform you're going to go with.
Click to expand...

Very true, but if you want a mainstream platform that works for 90% of applications then there is absolutely nothing wrong with .NET - you can apply it to more solutions than you might think. If you're developing commercially, my advice is don't be precious and snooty about what you develop in - use what gets the job done most effectively on a platform that's widely supported - e.g. ASP.NET has a whole lot of AJAX capable controls built in to it - so while it may be a great intellectual or coding exercise to write all your own javascript and XMLHTTP calls yourself, save that for when it's really needed, the client isn't going to care.

Clients want mainstream platforms, especially corporates. They've all been burnt in the past at some point by becoming reliant on key applications that turn out to have been developed by some guy who was a one man genius in perl or lisp or something and now that he's emigrated/retired/dead they find that either there's nobody with the skills to leverage their old code or the skills are rare and very expensive. The more mainstream your platform, the more supportable and future proof it will be, and the simpler your life will be when you have to maintain the code in two years time.

An article like this that blithely condemns anyone or anything to do with .NET is just plain stupid and speaks volumes about the author's prejudices and lack of insight into both the .NET platform and the development environment in general. It's the kind of dogmatic garbage that makes for an eye-catching article and not much more. McDonalds is one of the most successful companies in the world precisely because it is so standardized, sytematized and simple to operate - it produces results, efficiently, consistently and predictably. Why are these bad things in a development environment? They are exactly what we should be aspiring to as commercial developers.

I've seen a huge amount of projects go south because, for example, the client wants a simple online order/invoice system that can be banged out in ASP.NET in two days, but some self opinionated so-called hotshot developer decides the project must be some multi-tiered overcomplicated system with an Adobe AIR front end and a backend processing system in C++ and with data held in some convoluted XML format on a nosql distributable database, because "these are the best tools for the job". Six months later the client still doesn't have a working solution, but never mind because the interface is beautiful and the data model is a work of art.

Lastly, for what it's worth, .NET is not a "language" - it's a platform and you can develop using anything from C# to Ruby to Python with it. I seriously doubt the author has a clue about .NET.
 
Last edited:
My take on the whole situation:

Regardless of what the author thinks, I think .NET is a very strange product but wonderful for a developer that doesn't like making architectural decisions.
In .NET, you go the .NET way, there are no frameworks you have to choose or design decisions. You just do what MS say you should do and bam you have an application that runs pretty well.

My problem was however, I found myself writing boilerplate code many times in .NET and I wouldn't go back to .NET any time soon.
I've since found greener pastures (Spring Framework, Grails and Google Web Toolkit, all on Java EE) where I don't need to waste my timing writing back-end code or this and that for database access and what not. Worst is that in .NET the development tools try to generate that code for you but the level of coupling is so high, changing anything means you might as well start from scratch writing all your boilerplate code yourself. Goodness, they have a long way to go...

Java is just years ahead of .NET, I haven't looked at .NET in a while but things like dependency injection, ORM, MVC with plug-able views, aspect oriented programming, message queues, hell the list goes on. It just isn't there. There is no possibility of .NET catching up to Java EE IMHO, there is just too large a code base now. MS made a critical error when they kept .NET closed IMHO.

To me .NET is still just small business, where it is great because you can't afford architects and there are too many people who don't have a clue.

EDIT: I actually read the article again, and I see my own feelings almost completely reflect that of the author. LOL!

If you can't develop an application quickly in Java, you don't know Java! Or you aren't using the correct frameworks!
 
Last edited:
AcidRaZor said:
You can't apply .NET to everything, the same way you can't use PHP or jQuery or Classic ASP or Python or Ruby for everything. Several factors dictate which technology/programming platform you're going to go with. People/programmers tend to get stuck into one train of thought when they do get a project (or tender for one).

As an example, several years back I worked for a company that (probably still) uses Classic ASP and JavaScript as their platform. Using AJAX (before the term was even coined FYI) for their interface and a grid system written in JavaScript to leverage off "today's powerful PC's" to render sections of data useful to the end-user looking at it. When it was time for new programmers to join the fray they did. We taught them how the system/concept work. We trained them in our framework we wrote and we asked them to continue adding onto it for our clients.

Then one day a simple problem popped up where the client requested a file be delivered via the web app, but the file will be generated on a different domain. They were stumped. Cross-domain security screwed with their JavaScript calls and they couldn't figure out why. It took them 2 days before I stepped in and went "Why not just use a server-side XMLHTTP call to do that so that it always run on the same domain?" A simple solution to a problem they were struggling with but couldn't see since they only had 1 programming technology in mind they wanted it to work with _ALWAYS_

So when a client approaches me for a project, I go through several questions with them while drawing up the project outline and in there I then decide which is better to go with. I've seen companies force their clients to go with a Windows (or Linux) environment just because their "skills" didn't cover the other plethora of languages/platforms out there. Never to the benefit of the client, but the benefit of the programming house. I give the client what they want regardless of technology/platform/programming required. If it means I do something in Delphi, I will. Of course I will suggest other technologies that might better suit their needs, but it's up to them to decide that at the end of the day and I always love a challenge.
Click to expand...

nice post.
 
AcidRaZor said:
You can't apply .NET to everything, the same way you can't use PHP or jQuery or Classic ASP or Python or Ruby for everything. Several factors dictate which technology/programming platform you're going to go with. People/programmers tend to get stuck into one train of thought when they do get a project (or tender for one).

As an example, several years back I worked for a company that (probably still) uses Classic ASP and JavaScript as their platform. Using AJAX (before the term was even coined FYI) for their interface and a grid system written in JavaScript to leverage off "today's powerful PC's" to render sections of data useful to the end-user looking at it. When it was time for new programmers to join the fray they did. We taught them how the system/concept work. We trained them in our framework we wrote and we asked them to continue adding onto it for our clients.

Then one day a simple problem popped up where the client requested a file be delivered via the web app, but the file will be generated on a different domain. They were stumped. Cross-domain security screwed with their JavaScript calls and they couldn't figure out why. It took them 2 days before I stepped in and went "Why not just use a server-side XMLHTTP call to do that so that it always run on the same domain?" A simple solution to a problem they were struggling with but couldn't see since they only had 1 programming technology in mind they wanted it to work with _ALWAYS_

So when a client approaches me for a project, I go through several questions with them while drawing up the project outline and in there I then decide which is better to go with. I've seen companies force their clients to go with a Windows (or Linux) environment just because their "skills" didn't cover the other plethora of languages/platforms out there. Never to the benefit of the client, but the benefit of the programming house. I give the client what they want regardless of technology/platform/programming required. If it means I do something in Delphi, I will. Of course I will suggest other technologies that might better suit their needs, but it's up to them to decide that at the end of the day and I always love a challenge.
Click to expand...

I wish everybody had that view point, but we have too many people with their own ideologies running around.
 
garp said:
Very true, but if you want a mainstream platform that works for 90% of applications then there is absolutely nothing wrong with .NET - you can apply it to more solutions than you might think. If you're developing commercially, my advice is don't be precious and snooty about what you develop in - use what gets the job done most effectively on a platform that's widely supported - e.g. ASP.NET has a whole lot of AJAX capable controls built in to it - so while it may be a great intellectual or coding exercise to write all your own javascript and XMLHTTP calls yourself, save that for when it's really needed, the client isn't going to care.

Clients want mainstream platforms, especially corporates. They've all been burnt in the past at some point by becoming reliant on key applications that turn out to have been developed by some guy who was a one man genius in perl or lisp or something and now that he's emigrated/retired/dead they find that either there's nobody with the skills to leverage their old code or the skills are rare and very expensive. The more mainstream your platform, the more supportable and future proof it will be, and the simpler your life will be when you have to maintain the code in two years time.

An article like this that blithely condemns anyone or anything to do with .NET is just plain stupid and speaks volumes about the author's prejudices and lack of insight into both the .NET platform and the development environment in general. It's the kind of dogmatic garbage that makes for an eye-catching article and not much more. McDonalds is one of the most successful companies in the world precisely because it is so standardized, sytematized and simple to operate - it produces results, efficiently, consistently and predictably. Why are these bad things in a development environment? They are exactly what we should be aspiring to as commercial developers.

I've seen a huge amount of projects go south because, for example, the client wants a simple online order/invoice system that can be banged out in ASP.NET in two days, but some self opinionated so-called hotshot developer decides the project must be some multi-tiered overcomplicated system with an Adobe AIR front end and a backend processing system in C++ and with data held in some convoluted XML format on a nosql distributable database, because "these are the best tools for the job". Six months later the client still doesn't have a working solution, but never mind because the interface is beautiful and the data model is a work of art.

Lastly, for what it's worth, .NET is not a "language" - it's a platform and you can develop using anything from C# to Ruby to Python with it. I seriously doubt the author has a clue about .NET.
Click to expand...

Cant agree more...

I would love to see what the coding environment will be like in 5 years time, things changes so quickly I wonder who and what will keep up.
 
I see this problem [-]all[/-] some of the time.

Our windows development language of choice is C#, but as soon as you want to do some crazy WinAPI/COM/ActiveX/Whatever that's not supported by the framework you're screwed.
 
Last edited:
Gnome said:
If you can't develop an application quickly in Java, you don't know Java! Or you aren't using the correct frameworks!
Click to expand...
Same goes for .Net. Only difference being that .Net IS the framework. :)

Truth be told, I love the .Net framework - it has put my kids through school, after all - but I keep myself busy with PHP/HTML/JS after hours just to keep my mind fresh and agile. Sure, there are .Net developers out there that can only code .Net, and fail to understand the architecture below it - but in turn there are plenty of .Net developers that can break down their (and your) code and explain exactly what is happening below it. In my opinion, it benefits you to know what is going on beneath the covers, as it were.

Gnome said:
To me .NET is still just small business, where it is great because you can't afford architects and there are too many people who don't have a clue.
Click to expand...
Not true. I've worked in many .Net houses, and only one was a small business. Even that one was a dev house with large corporate clients, and I've always worked with analysts. That was a short-sighted remark, dude. I expected better from you. ;)
 
dequadin said:
I see this problem all the time.

Our windows development language of choice is C#, but as soon as you want to do some crazy WinAPI/COM/ActiveX/Whatever that's not supported by the framework you're screwed.
Click to expand...

Dude .net does com and winapi etc.. Google is your pal :)

Otherwise fire up the old C++ :)
 
I think that what the article is trying to convey is, that it doesn't say that .net is bad, but they want someone who knows how things are pieced together at a lower level...someone who can think out of the box and not only depend on the tools within .net...that's all.

They want someone with a broader understand, an understanding preferably outside of the .net world coupled with a .net understanding.
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X