It’s SharePoint’s world. We just develop in it.
This sentiment is all too familiar to many SharePoint devs I have spoken with, including myself. Solid developers—but mired in the constraints of a platform whose boundaries are not always clear.
Here’s the thing. SharePoint is not a platform for developers—it’s a productivity tool that empowers end users. The fact that there are as many places in its pipeline for .NET nerds to stick their considerable proboscises into as there are is actually pretty generous.
Any platform derives its value from the altitude of its starting point. The price of the ticket to this altitude is the loss of control over exactly where you can go from there.
Happy SharePoint developers understand its power and embrace its constraints. If all you notice is how much the SharePoint infrastructure seems to get in your way, or you mope through your tasks under a cloud of “we don’t have to do it this way in regular ASP.NET”, you are sure to miscalculate your code’s relationship with its host, and many of the little decisions you make every day as a developer will be skewed, or even straight up wrong.
When you know and embrace your platform, however, something excellent happens. The big picture comes into focus, and you are set free to see new patterns and approaches to your work. Specifically, you gain a better understanding of what code belongs within the constraints of SharePoint, and what code does not. For example? Sahil Malik has long been an advocate for SharePoint solutions as lightweight clients to WCF services that house the real .NET nitty-gritty of the application. And my new favorite MVP du SharePoint, Jason Kaczor, relates here how he eschews Web Parts altogether, and develops nimble HTML5 code that accesses SharePoint data via its OData feeds.
Wait. You didn’t know that SharePoint exposes its data in OData feeds?
Know and embrace your platform.