I’ve been working with SharePoint more or less full-time from about 2006/2007 now, as consultant, doing so in a variety of projects and clients.
One thing they, the projects and client, all have in common (if I’ll try to look in rear-view mirror) is that I was brought in because I knew a thing or two about SharePoint, I had the “expertise” that the customer required so to say.
Not so strange when you’re working as a consultant right…that you’re hired for your expertise?
Well, no (duh)…but most of these assignments had me working with things that are not relevant, or should I say not looked on as relevant, when you work as a “SharePoint developer”.
With relevant I mean that the assignment description most often said something like ‘expertise in SharePoint…’ but in fact that was a pretty small part of the knowledge you had to bring in order to successfully complete the assignment.
My point being that SharePoint, and precisely SharePoint development, is often thought of as a thing of its own and not a specialization of web development on the .NET platform.
Am I SharePoint developer then?
If you ask someone who knows me (job-wise) what I do, my expertise in other words, I guess that they would say (not all of them though):
He’s a SharePoint developer…
But if you ask me personally, the answer would be something like…:
I’m a developer that’s currently working within the realms of the Microsoft web development stack.
So I consider myself to be a web developer. That means that I work in realms of the web development stack, more specifically, the Microsoft .NET web development stack. (i.e. .NET –> ASP.NET –> IIS related concepts and products/frameworks…SharePoint being an example of such a product actually).
I didn’t start my development career in SharePoint but it has become quite a big part of my knowledge base…my edge so to say.
If we’re looking at the past 112 posts from my blog and only looking at the at the category, how I’ve categorized them, the greater part of them are about SharePoint.
Looking at actual content though reveals:
So what I’ve done here is to go over the posts and looking at what they actually touch upon, the content.
Interestingly, more than half of them (62%) are not about SharePoint. They might use SharePoint as an example but the actual content is not at all related to the product.
An example could be that I’ve written about dependency injection and used SharePoint to show how you can use dependency injection inside SharePoint. The actual content of the post, what it tries to highlight, however would be that dependency injection is a great development practice.
In one of those posts on dependency injection I got a comment saying that my article had nothing to do with SharePoint (see image below)…who knew right?!
That’s precisely the problem…developers working with SharePoint have stopped caring (not all of them…I generalize a bit I know) about .NET and products/frameworks related to the .NET web stack and specifically about development best practices.
Let me explain…
Things like Entity Framework, NHibernate etc. exist to make things easier for us when we write code against databases.
That doesn’t mean that we could, or even should, stop caring about how databases work.
An even better example is LINQ. When LINQ came with .NET 3.5 developers started using it against SharePoint lists (Linq-To-Objects in fact) without knowing how that would affect the performance.
What actually happened was that these “SharePoint developers” missed checking how LINQ actually works, i.e. what deferred execution is really all about etc.
Some “SharePoint developers” I’ve met think it’s enough to know some parts of the SharePoint API to get around (Lists, Content Types, Web|Site etc.) and how to build web parts (thus putting all the code in the code file that makes up the web part).
I think it’s critical to fully understand that SharePoint is built on top of IIS and then you have to know how that works in order to be successful (e.g. virtual directories , virtual paths providers etc.), especially when problems arise.
Then apply your SharePoint expertise on top…and boom you’re one of the best!
Why is this happening?
Maybe it’s because SharePoint has so many pitfalls (API wise) that you have to know about (disposing objects correctly being one of them) that you simply have not time/interest to get to know all these things that we have to master in order to be successful.
So what do we need to know then?
What should a SharePoint developer have knowledge about then? (according to me at least). Here’s some things at minimum:
- Basic understanding of the usual Design Patterns – The GOF patterns or the GRASP patterns should be a good starting point.
- Deep understanding of:
- Understanding Cohesion And Coupling
- Domain Driven Design in theory. Concepts behind it.
- TDD, BDD (at least in theory).
- Some UI patterns (MVC, MVVM, MVP).
- Ask the questions WHY am I building this code and have I written it before (DRY).
- At least have read one C# book or stay up-to-date with how to use the language and its features.
- At least have read one ASP.NET book (not ASP.NET MVC or WebForms) just so you know how ASP.NET works especially when it comes to IIS…SharePoint builds on top of IIS (don’t you forget it)
…and on top of that add required SharePoint knowledge (which may differ from project to project and will of course increase over time) but at a minimum:
- SharePoint API/OMs
- How to install and setup a SharePoint farm
- Basic knowledge on what’s available OOB (you should be able to do a quick presentation)
- How to develop for SharePoint from Visual Studio (specifically how to deploy your stuff)
Are you a SharePoint developer or a developer with skills/expertise within SharePoint?
I know which category I ‘d consider myself to fall under.
The requirement that it’s not enough to know a thing or two about web parts and page layouts to be a web developer working with SharePoint will be even more important with SharePoint 2013.
btw: I’ve also categorized this post SharePoint, just so you know.