A little more than a year ago, I was, as someone looking for .Net developers that knew the SharePoint API, frustrated by the confusion in the SharePoint space between the different kinds of developers that exist in the ecosystem. This confusion persists to this day, much to the detriment of both these developers and the people that want to hire them.
This needs to stop.
.Net developers in the SharePoint space have gotten awfully defensive in the last few years, and I can't blame them. Microsoft keeps moving their damn cheese, and for some, has been taking the cheese away entirely. The job opportunities in the SharePoint-.Net space are shrinking, and so these developers are doing whatever they can to defend this space. Unfortunately, this often includes berating the other types of developers as "not real developers" as often as they can.
This needs to stop.
"So..."
you might ask.
"...what do we call these different roles?"
That, friends, is the easy part. Also? It turns out there are 3 disparate groups here, each worth giving their own share of the limelight. I propose we start naming these different types of jobs as such:
-
.Net Developers
This is the easy one — if you use Visual Studio to compile .Net code into DLLs that are then packaged up and pushed, this group is for you. -
Front-end Developers
These are folks that live & breathe JavaScript, HTML, and CSS and somehow wound up working on SharePoint stuff. Branding folks, UX/UI people, SharePoint-hosted app developers: these are your people. -
SharePoint Developers
These developers are the ones that are creating the increasingly complex solutions in SharePoint that you'll often see referred to as "no code" solutions. These developers know the product inside and out, can do more in a day with SharePoint Designer and InfoPath than you'll get done in a week in Visual Studio, and know when the .Net developers are coding something custom that already exists. Power users, analysts, SharePoint Designer people, InfoPath people, this is your group.
Now, I can already hear the people in groups 1 & 2 already complaining.
"But I'm a SharePoint Developer tooooo"
Yes, yes, of course you are. Here's your cookie.
"But those people aren't developers at alllll, they don't even know how to do $thing_I_know_how_to_do"
Don't be a child. You weren't born with innate knowledge of how to do what you're doing, your path is your own and no one else's, and who the hell are you to decide who makes the mark?
Now shut up, adults are talking.
Some people will inevitably fall into more than one category; some people may cover all 3 to an extent, but anyone claiming they're at the top of the game for all three is probably full of crap. People that can cover all three at the expert level are unicorns, and will probably be the very last people to tell you they're experts in any group, never mind all 3.
Lastly, who the hell am I to be deciding any of this?
Well, first, if you think I have that kind of power, to decide something and have it be so... HA. If only, friend... if only. Secondly, I run two SharePoint conferences and a user group in the NYC metro area. As such, I have to design session tracks that make the most sense for attendees to follow, and for speakers to best target their session content. Ambiguity in what a session might be, ambiguity in what audience a session might serve: these are my enemies.
Consequently, for my conferences, I'm going to start naming these groups — and the tracks for those groups — as laid out above. I'm going to encourage other organizers and speakers to use the same nomenclature, to help get the word out. I'm going to refer to these roles for any job description I need to write, and in any interview I conduct.
And, I'll kick out anyone from my events I hear deriding the other groups as "not real developers"... you people are a poison in the community, and we're better off without you.
Think I'm full of crap? Let me know on Twitter, or come find me at SharePoint Saturday Virginia Beach on January 11th.