A few days ago Stacy Draper and I were chatting about what it means to be a SharePoint Developer. That actually turns about to be a conversation with lots of shades of grey. Stacy thought it would make a good blog post… well, I can’t promise this to be a GOOD blog post…
So, anyway, I decided to let off a little bomb this morning by posting the following tweet on Twitter:
@mrackley: Can someone be considered a SharePoint Developer if all they know how to do is work in SPD?
Now, I knew this is a debate that has been going on since the first SharePoint Designer User put SharePoint Developer on their resume. There are probably several blogs out there on the subject, but with the wildfire that is jQuery and a few other new features out there I believe it is an important subject to tackle again. I got a lot of great feedback as well on Twitter. The entire twitter conversation is at the end of this blog posting. Thanks everyone for their opinions.
Who cares? Why does it matter? Can’t we all just get along?
Yes it matters… everything must be labeled and put in it’s proper place. Pigeon holing is the only way to go! Just kidding.. I’m not near that anal, but yes! It is important to be able to properly identify the skill set of those people on your team and correctly identify the role you are wanting to hire. Saying you are a “SharePoint Developer” is just too vague and just barely begins to answer the question.
Also, knowing who’s on your team and what they can do will ensure you give your clients the best people for the job.
A Developer writes code right? So, a Developer uses Visual Studio!
Whoa, hold on there Sparky. Even if I concede that to be a developer you have to write code then you still can’t say a SharePoint Developer has to use Visual Studio. So, you can spell C#, how well can you write XSLT? How’s your jQuery? Sorry bud, that’s code whether you like it or not. There are many ways to write code in SharePoint that have nothing to do with cracking open Visual Studio.
So, what are the different ways to develop in SharePoint then?
How many different ways can you “develop” in SharePoint?? A lot…
Out of the box features
In SharePoint you can create a site, create a custom list on that site, do basic calculations in a calculated column, set up alerts, and add all sorts of web parts to a page. Let’s face it.. that IS development!
Ahhh.. The cause of and the answer to all of your SharePoint development problems. With SharePoint Designer you can use DataView Web Parts, develop (there’s that word again) your branding, and even connect to external datasources. There’s a lot you can do in SharePoint Designer. It’s got it’s shortcomings, but it is an invaluable tool in the SharePoint developers toolbox.
So, can InfoPath development really be considered SharePoint development? I would say yes. You can connect to SharePoint lists, populate fields in a SharePoint list, and even write code in InfoPath. Sounds like SharePoint development to me.
Visual Studio – Web Services/WCF
So, get this. You can write code for SharePoint and not have a clue what the 12 hive is, what “site actions” means, or know how to do ANYTHING in SharePoint? Poppycock! You say? SharePoint Web Services I say… With SharePoint Web Services you can totally interact with SharePoint without knowing anything about SharePoint. I don’t recommend it of course, but it’s possible. What can you write using SharePoint Web Services? How about a little application called SharePoint Designer?
Visual Studio – Object Model
And here we are finally: the SharePoint Object Model. When you hear “SharePoint Developer” most people think of someone opening Visual Studio and creating a custom web part, workflow, event receiver, etc.. etc.. but I hope that by now I have made the point that this is NOT the only form of SharePoint Development!
Again… Who cares? Just crack open Visual Studio for everything! Problem solved!
Let’s ponder for a moment, shall we? The business comes to you with a requirement that involves some pretty fancy business calculations, and a complicated view that they do NOT want to look like SharePoint. “No Problem” you proclaim you mighty SharePoint Developer. You go back to your cube, chuckle at the latest Dilbert comic, and crack open Visual Studio. Then you build your custom web part… fight with all the deployment, migration, and UAT that you must go through and proclaim victory two weeks later!!!! Well done my good sir/ma’am! Oh wait… it turns out Sally who is not a “developer” did the exact same thing with a Dataview web part and some jQuery and it’s been in production for two weeks? #CockinessFail
I know there are many ASP.NET developers out there that can create a custom control and wrap it to be a SharePoint Web Part. That does NOT mean they are SharePoint Developers though as far as I’m concerned and I personally would much rather have someone on my team that can manipulate the heck (yes, I said ‘heck’) out of SharePoint using Dataview Web Parts, jQuery, and a roll of duct tape.
Just because you know how to write code in Visual Studio does not mean you are a SharePoint Developer.
What’s the conclusion here? How do we define ‘it’ and what ‘it’ is called?
Fortunately, this is MY blog. I don’t have to give answers, I can stir the pot, laugh and leave you to ponder what it means! There is obviously no right or wrong answer here (unless you disagree with me,then you are flat out wrong). Anyway, there are many opinions. Here’s mine. If you put SharePoint Developer on your resume make sure to clearly specify HOW you develop in SharePoint and what tools you use.
If we must label these gurus of jQuery and SPD, how about “SharePoint Client Developer” or “SharePoint Front End Developer”? Just throwing out an idea. Whatever we call them, to say they are not developers is short-sighted, arrogant, and unfair. Of course, then we need to figure out what to call all those other SharePoint development types.
@next_connect: RT @mrackley: Can someone be considered a SharePoint Developer if all they know how to do is work in SPD? | I say no....
@mikegil: @mrackley re: yr Developer question: SPD expert <> SP Developer. Can be "sous-developer," though. #SharePoint #SPD
@WonderLaura: Rt @mrackley Can someone be considered a SharePoint Dev if all they know how to do is work in SPD? -- My opinion is that devs write code.
@exnav29: Rt @mrackley Can someone be considered a SharePoint Dev if all they know how to do is work in SPD? => I think devs would use VS as well
@ssKevin: @WonderLaura @mrackley does that mean strictly vb and c# when it comes to #SharePoint ?
@jimmywim: @exnav29 @mrackley nah, I'd say they were a power user. Devs know their way around the 12 hive ;)
@sympmarc: RT @mrackley: Can someone be considered a SharePoint Developer if all they know how to do is work in SPD? -> Fighting words.
@sympmarc: @next_connect @mrackley Besides, we prefer to be called "hacks". ;+)
@next_connect: @sympmarc The important thing is that you don't have to develop code to solve problems and create solutions. @mrackley
@mrackley: @sympmarc @next_connect not tryin to pick fight.. just try and find consensus on definition
@usher: @mrackley I'd still argue that you have a DevLite title that's out there for the collaboration engineers (@sympmarc @next_connect)
@next_connect: @usher I agree. I've called it Light Dev/ Configuration before. @sympmarc @mrackley
@usher: @next_connect I like DevLite, low calorie but still same great taste :) @mrackley @sympmarc
@mrackley: @next_connect @usher @sympmarc I don't think there's any "lite" to someone who can bend jQuery and XSLT to their will.
@usher: @mrackley okay, so would you refer to someone that writes user controls and assemblies something different (@next_connect @sympmarc)
@usher: @mrackley when looking for a developer that can write .net code, it's a bit different than an XSLT/jQuery designer. @sympmarc @next_connect
@jimmywim: @mrackley @sympmarc @next_connect I reckon a "dev" does managed code and works in the 12 hive
@sympmarc: @jimmywim @mrackley @next_connect We had a similar debate a few days ago @toddbleeker et al
@sympmarc: @sympmarc @jimmywim @mrackley @next_connect @toddbleeker @stevenmfowler More abt my Middle Tier term, but still connected. Meet bus need.
@toddbleeker: @sympmarc @jimmywim @mrackley @next_connect I used "No Assembly Required" in the past. I also suggested "Supplimenting the SharePoint DOM"
@toddbleeker: @sympmarc @jimmywim @mrackley @next_connect Others suggested Information Worker Solutions/Enhancements
@toddbleeker: @sympmarc @jimmywim @mrackley @next_connect @stevenmfowler I also like "SharePoint Scripting Solutions". All the technologies are script.
@jimmywim: @toddbleeker @sympmarc @mrackley @next_connect I like the IW solutions one...
@toddbleeker: @sympmarc @jimmywim @mrackley @next_connect @stevenmfowler This is like the debate that never ends: it is definitely not called Middle Tier.
@jimmywim: @toddbleeker @sympmarc @mrackley @next_connect @stevenmfowler "Scripting" these days makes me think PowerShell...
@sympmarc: @toddbleeker @jimmywim @mrackley @next_connect @stevenmfowler If it forces a debate on h2 best solve bus probs, I'll keep sayin Middle Tier.
@usher: @sympmarc so we know what we're looking for, we just can't define a name? @toddbleeker @jimmywim @mrackley @next_connect @stevemfowler
@sympmarc: @usher @sympmarc @toddbleeker @jimmywim @mrackley @next_connect @stevemfowler The naming seems to matter more than the substance. :-(
@jimmywim: @sympmarc @usher @toddbleeker @mrackley @next_connect @stevemfowler work brkdn defines tasks, defines tools needed, can then b grp'd by user
@WonderLaura: @mrackley @toddbleeker @jimmywim @sympmarc @usher @next_connect Funny you're asking. @johnrossjr and I spent hours this week on the subject.
@stevenmfowler: RT @toddbleeker: @sympmarc @jimmywim @mrackley @next_connect @stevenmfowler it is definitely not called Middle Tier. < I'm with Todd