Did quite a bit of blog reading tonight, mostly related to SharePoint, and it has prompted me to reflect the last 3 years and how my attitude towards SharePoint has gradually shifted. 

Here is a journey of a .NET developer who stumbled upon a technology called SharePoint, and finally made some sense of it.

2004: Does the world really need another Portal Software?

It was 2004 when I first head about this SharePoint portal server.  At the time where everyone was busy building first .NET applications, then ASP.NET applications.  The world was different then, perhaps a bit more black and white and mostly in code.

Everyone is out there building portals with web technologies, and failing that… build an engine for other people to build their portal upon.  Community Server, DotNetNuke, DasBlog… and these were the good ones.

So here’s this silly product from Microsoft, called SharePoint.  Immediately dismissed as a DotNetNuke –ish portal software and promptly forgotten.

2007: Many software seems to be built on top of the SharePoint platform, what is it?

I was working elsewhere in 2007.  Happily working on ASP.NET with nhibernate and spring.net.  SharePoint, unsubtly, crawled in front of the view screen again.

What intrigued me then was that Microsoft was refusing to let SharePoint die.  What surprised me was that it was no longer the portal software that I had in mind.  It had become a platform.

Still, I wouldn’t have given up my freedom with writing my own code to live within the confines of another platform that isn’t built by me.  (the "not invented here" syndrome)

So, performance point and BI flew past me.  Though in hindsight, I’m still pretty sure I wasn’t interested in that type of work…  May be in another decade I’d say differently.

2008: Jumping in the deep end.  The wars between SharePoint vs. Developer

I jumped into SharePoint some point in early 2008 – we were working on a heavily customized SharePoint publishing site, and there are a few areas where we needed the ASP.NET muscles to force SharePoint to bend to our will.  Considering myself an ASP.NET blackbelt, I jump in to sumo wrestle with the giant that is SharePoint.

I won.  Most of the time.  But SharePoint made me pay for my victories.  Years later, there are battle scars and silent tears for the hours that was thrown in to fight SharePoint.

It is in those hours that I learned:

• Why you should always build SharePoint packages, and have development, staging (test/UAT), and production SharePoint servers.
• Remembering the un-ghosted files
• Why SPDisposeCheck is awesome, because… if you don’t use it… the result is really un-awesome (see next point).
• How to read SharePoint logs – aka damn you SharePoint I hate you why do you hate me so
• Speak CAML – aka SharePoint gibberish
• Overwriting SharePoint with HttpModules
• Tell SharePoint (actually ASP.NET) to stop rendering those tables , and sigh the default masterpage is unusable

2009: Seeing SharePoint for what it really is.

Perhaps my lessons came later.  Perhaps it’s seeing the unnecessary wounds that I earned from wrestling, that got me to sit down, and work out what is SharePoint.  And what is the right thing to do.

So half way through 2008 and throughout all of 2009, I tell myself OK.  I’m going to give myself and this thing one chance and really work out what SharePoint is.

The Internet does not fail, and SharePoint knowledge is out there, free for you to find and to read.  The funny thing is that all these information has always been available.  But perhaps I was just too stubborn to turn my head to have a good look at SharePoint. 

If you want a reading list, this is the biggest list I could find:
http://www.dynamicevents.com/MCM/MCMSharePointPre-Reads.pdf
Recommended reading list for Microsoft SharePoint Certified Masters.  There are 81 articles and some are reference books.  You will probably never finish reading before SharePoint 2010 comes out with more required reading.

2010: At the edge of my seat.

As SharePoint became fun, I come to enjoy working in this platform.  Around mid 2009 after prompting from boss Adam Cogan, I wrote a brief presentation of 8 things I really wish SharePoint 2007 could do better, for me as a developer.  And presented it in Adelaide and Sydney SharePoint user groups.

As Microsoft show its hands with SharePoint 2010, I worked to update the same presentation to see if MS has addressed my wishes.

Somewhat surprisingly, Microsoft addressed almost all my annoyances.  From CAML, packaging, debugging, BCS, search, and even a much cleaner DOM for our designers.

And even added more that I wasn’t too worried about: Silverlight, OData, ribbons and enterprise taxonomy.

Looking back over the last 3 years, our internal SharePoint installation has turned from an “oh we have a SharePoint running here somewhere” service, to an “essential production” service.  There was a time where if mail wasn’t available people would complain within 10 minutes, but SharePoint may be down for extended periods of time without people noticing or caring.  Not anymore.  Now, if SharePoint is unavailable for just 5 minutes due to a feature upgrade, you will hear people complain.

Too much writing, time to wrap it up

There’s still plenty more things to do in SharePoint, and plenty more things to do with SharePoint.  I’m glad I jumped on this path.  No idea where I’ll be in another 10 years, but I think I’ll always look back on 2010 with much fondness.