During our respective journeys with SharePoint, we invariably come across issues with the application, API, and tools, that annoy us. IMHO, one of the things that makes a good SharePoint developer is patience; the ability to put up with a development effort that is naturally less productive than traditional ASP.NET development, due to the additional layers SharePoint brings to the table. This requires a little appreciation for what SharePoint is giving you at the other end - a whole lot of stuff you don't need to develop yourself (anyone want to come up with a Content Management framework in a weekend?), and a platform on which to build in the future. And, in the case of issues, bugs, and shortcomings, I also find that a little empathy goes along way.
Yes, Microsoft have built a platform that has some shortcomings. Yes, there are limitations with the API and tools. Yes, they're
making a truckload off SharePoint - but does that mean it is or should be perfect? No. I'm not making excuses for bugs and a lack of testing - God knows they can afford it - but I am saying that it's difficult for anyone to get it right without full exposure to all the possible real world permutations of use. And for an enterpise application platform like SharePoint - that's a
lot of permutations.
So - instead of moaning - find a solution, post a workaround, or build a product to plug the gap, then send your feedback to Microsoft through your local MVP or community leaders, who usually have a direct line to the product teams. If the pain points are communicated frequently enough, they'll get through. It's then up to Microsoft to act on this in service packs or in vNext, and in recent years I've seen an increasingly open and collaborative Microsoft. It seems they now understand that in order to get it right, they need to support, encourage, and listen to the community. This is part of the reason I enjoy running the
SharePoint User Group.
One final word of advice to frustrated SharePoint developers - if you're expecting to get results with little or no training, then think again, and stop blaming SharePoint. In my opinion, being a good SharePoint developer requires understanding what's going on at a theoretical "big picture" level. If your boss dumps you on a SharePoint project and you don't know the difference between customised and uncustomised pages - it's a bad start. If you don't know the best practices around packaging functionality into Features and Solutions, then you're already handicapped. If you just want to cut and paste code and expect it to work without comprehension, then the red flags are flying. And further, if your attitude is fooling you into thinking it should be just as easy as ASP.NET development, and Microsoft somehow owes you this, then you're expecting something for nothing, and perhaps SharePoint development isn't for you.
On the other hand, if you're prepared to
attend a training course or
read a book to gain understanding first, and will even go so far as to
demand this of your boss before you get dumped in the deep end, then you'll do well with SharePoint. If you're naturally someone who gets passionate about the application you are working with, and the business outcomes it can provide, then you'll also do well, because SharePoint success breeds success. Also, if I was recruiting for a top notch SP developer, and they weren't subscribed to
at least 50 blogs, then I would say they don't "get" what is necessary to work with a platform where the best practices and real world tips will come over time, the community owns the content, and the only constant is change.
So... with a little Patience, Appreciation and Empathy, SharePoint will surely PAE off for you!
:) Matt
PS In the interest of not being a hypocrite, I'm going to start posting some of my "vNext Wishlist" as they come up. Stay tuned, Microsoft (or 3rd party product developers!)!