What makes .NET developers/experience so special?

Question

Many are I'm sure familiar with the fact that lack of work experience with C# and .NET can create real career advancement impediments for Windows programmers. .NET was designed with the intention of making software development easier. The runtime's event model makes GUI programming more convenient than using MFC, WTL, or VB. ASP.NET offers clear superiority over the ASP VBScript/IDispatch runtime. ADO.NET is in many ways more clearly thought through than ADO. .NET assembly versioning is a lot easier to deal with than that offered by COM.

Yet, years of experience with the .NET environment is a strong prerequisite for most positions that I see advertised. This usually trumps other possible considerations like depth of experience with complex codebases, troubleshooting skills, etc.

It suggests that .NET's 2001-2002 vintage marketing hype didn't really convert into reality -- there must be nuances within the CLR that are lost on those who may have grown up on a diet C++, VB, and COM.

Apart from obvious things like parameter passing, interfaces, object lifetime management, gui resources, and language syntax changes, what are the battle scars that distinguish experienced .NET developers? Book and article recommendations are greatly appreciated.

This is not meant as a disingenuous question.

Answer 1

My personal experience with this kind of argument: If somebody has never done anything else, they will naturally presume, that it takes X years of experience in that technology to be any good. With X being somewhere in the ballpark of that persons own experience.

C# and Java, being "rule the world" environments with everything done their way (but I must say that C# is a little bit better here...) will attract these one-language-only types.

If you look into fancier stuff, scripting languages, exotic languages, functional stuff - you are generally looking at people who have seen a lot of different environments. These people will be more open to the idea that anyone with enough experience in general will pick up .NET in relatively short time. The system is pretty self describing.

Answer 2

HR types and recruiters, in general, do not know the difference between .NET and .com

but there is a learning curve for the .NET framework, just as with any framework/library of significant size (and the .NET framework is so large that no one knows all of it well)

so they ask for X years of experience with language L hoping to find a developer who can get the job done

aside: it is not uncommon to see job ads asking for 5 years of experience in language L when language L has only been on the market for 2 years. This is a sure sign of a job ad written by an HR drone ;-)

and .NET is not alone in this - many ads for Java or Ruby programmers have the same 'N years of experience in language L' flavor

Answer 3

IMX, the major battle scars relate to the sheer size of the .NET Base Class Library rather than CLR and language nuances. Almost anything you want is available somewhere in the BCL, but it takes a year or three of working with it to know where to look.

Sometimes the sheer accumulation of facts can be as important as talent or skill.

Answer 4

Most employers want "some experience" not matter what, so if they are looking for 2year .Net experience, because .Net is what they work with so it is there for the logical question to ask, i expect however that if you sent in your CV with 10 year VB experiance and 1 years VB.Net experience they would still look at it

The other side of the coin is that it makes it a lot easier to do a lot of thinks, so therefore theres a lot more to know, so more experience is required, (speaking as a VB developer) it's a lot bigger language

Answer 5

I'll go after your closing question... "what are the battle scars that distinguish experienced .NET developers?"

First, you're right that .NET was/is intended to make Windows development easier. That's not the same as making it EASY.

As a hiring manager, there are things I'm looking for that tell me that the candidate has gone beyond the basics. By "basics," I'm referring to the things you mention like parameter passing, object lifetime management, or building/managing GUI resources.

I want to know that the candidate has some depth with the framework. Do they go beyond those basics into more advanced areas? Have they created custom attributes? Why? Do they understand why IDisposable is so important? Have they worked with reflection and what problem did they use it to solve? What I'm not interested in is someone who can use a DataAdapter and a connection string to populate a Dataset.

I want to know that the candidate has some depth with the CLR. Do they understand what an AppDomain is? How loading things into it works? Do they understand how to marshal things across AppDomains and when/why they might want to? Can they speak to how the GC works and when/why they might tinker with it?

I want to know that the candidate has some depth with the tools. Can they talk about more advanced debugging techniques? Do they have some of those battle scars for dealing with hard-to-track runtime problems? Could they create a visualizer? Do they know their way around System.Diagnostics for the purpose of getting to the root of a problem quickly. Have they used third-party tools to make their life easier? Performance analyzers, unit testing frameworks, proven third-party libraries, etc...

Finally, I want to know that they "get" design in a meaningful way. When do you create an abstract class versus creating an interface? When does inheritance fit better than composition? Provide some examples of creating your own interfaces and why that was useful. Do they understand the meaning behind programming to an interface rather than an implementation... and can they do that while producing their OWN interfaces, rather than as a consumer of someone else's API.

Syntax is the easy part and I don't expect someone to memorize obscure trivia about the framework - but I want them to know what's out there so they're not reinventing the wheel... and there's no shortage of samples out in the world that will get nearly any development job "done." But do they know how to get that job done well? In a way that's maintainable, extensible, and provides long-term value after release.

There's my $.02.

Answer 6

Programming in .NET is very different from programming C++ or VB. You need .NET experience to be a good .NET developer - or experience from a similar high-level object-oriented language.

The .NET languages are more advanced languages than VB. It's not so much about the size of the CLR but about language concepts. .NET is far more object-oriented than old-style VB (although VB had some object-oriented features), and getting used to that is no small task. You can learn the syntax rules quickly - the hard part is getting used to a new way of thinking. It is far too easy to think that your experience from VB means that you know VB.NET, but to then end up write VB-style code in VB.NET. I have seen a perfectly competent VB developer fail miserably at taking the step up into VB.NET for exactly that reason.

If I was looking to hire a developer for a .NET position, and they had limited .NET experience but knew other languages, I would look for signs of real understanding of object-oriented design, above all. I would be less concerned about their knowledge of specific tools and technical details - they can pick that up later.

Answer 7

Yet, years of experience with the .NET environment is a strong prerequisite for most positions that I see advertised

This is because most positions are 'filtered' by recruiters or HR people, who don't know .NET from a fishing rod, so they effectively build a checklist of "2 years experience in X" because well, that's all that they can ask.

Answer 8

Perhaps it's as simple as you want them to be a good fit with the development organization and application base as it currently exists.

Answer 9

Try taking a lot of the Microsoft .Net exams, passing them may get you though the door…