On being a "SharePoint" expert

Recently Rocky had one of his many pearls of wisdom, that of the software development world becoming a specialization due to the complexity of the industry. Let me tell you that a) I agree with Rocky 100% (and more if anyone could agree more than 100%) and b) this is true especially so for SharePoint developers and 2007 (the version, not the year).

Actually, let me quantify that. What is a SharePoint developer? Is it a ASP.NET developer who knows a lot about the SharePoint API or is it a SharePoint developer who knows a lot about the ASP.NET API? The answer is yes.

Take me for example, I really didn't do a lot of ASP.NET development (about a year or so since B1) so other than little apps, the odd web service, etc. I really didn't have an in-depth experience being an ASP.NET developer. When I got the SharePoint itch I scratched it with what little COM+, ASP and structured development techniques I knew (we're talking back in STS and SPS 2001 days, before the .NET version). With v2 and 2003 came .NET and more knowledge of how IIS worked, ASP.NET server controls and all that goodness. Now here's 2007 and we're dealing with ASP.NET 2.0, security and membership providers, master pages, user controls, workflow, and a million other little tips, tricks and gadgets that would drive anyone batty.

It's just too much for any one brain to handle (except maybe Hanselman, but we all know he's not human anyways). And there's more to come! Upgrading from ASP.NET 1.1 to 2.0 was a huge shift for SharePoint (in fact a complete flip of the architecture, literally) but moving to 3.0/3.5 isn't going to be that much of a big deal. It's just a different version of the API, a set of new dlls, some Atlas thrown in. Basically a service pack, not a full blown release. With that will come all kinds of things. How about LINQ for SharePoint? We already have people writing PowerShell servlets that will treat SharePoint sites as folders you can navigate, so querying a SharePoint list shouldn't be any more difficult than using LINQ to query a list of objects.

The future is here and moving fast. Being a SharePoint expert isn't just about knowing all the technologies, layers, and tiers that encompasses SharePoint because frankly that's not realistic. SharePoint is just another layer in the stack, another tool in the toolbox, for us "developers" to work with. Whether we choose to weigh more heavily on the SharePoint API or the ASP.NET one, it's just a matter of what we're trying to accomplish. Being a SharePoint expert is about knowing what's available and making use of it, and getting the guys who really know this stuff inside and out to build it for you (or if you're that guy, build that part yourself).

I think gone are the days where being a SharePoint expert meant you knew every nut and bolt of every piece of the machine. Today, you're lucky if you can get your head wrapped around one part of it.

1 Comment

  • Bill,

    Couldn't agree more (more than 100%?). SP 2007 is such a beast that I can't see anyone being an "expert" at all of it - especially not this early in the game. I've been working with the silly thing since Dogfood4 and I KNOW I don't know it all. Tack all of the changes in ASP.Net 2.0 AND the 3.0 Framework onto that and the problem is just compounded. The trick, and you touched lightly on this, is that to be a "SharePoint expert" you need to know the breadth of the tools (SP, ASP.Net, Workflow, etc) to know what to use where, and you need to then have depth in a few areas. That depth is what will grow with time and experience. The breadth is what lets you figure out which pieces to use for a particular project and when you need to either pick up some depth or else call in someone who is already there.

    That is the strength I see in the SP community. All of the people who have depth in certain areas who share that knowledge help everyone else who is not an expert in that particular area. Everyone takes a small step forward by sharing what they know.

    -Dave

Comments have been disabled for this content.