Become a great SharePoint developer in 10 easy steps

The job market for SharePoint developers is really hot lately, and right now it’s a really nice place to be from a career perspective. There just doesn’t seem to be enough of us around, and those who are can expect to be courted quite aggressively by recruiters (at least that has been my experience). With that in mind I thought I’d put together a list of steps to becoming a great SharePoint developer and getting in on the action:

1. Be (or become) really good at solving problems. When developing SharePoint solutions, you will quite often find yourself doing things that no one has ever done before. While this is true for any type of software development(I mean, if someone else has already done it they’d just use that), it seems especially true for SharePoint development, for a number of reasons:

a. There are just not that many SharePoint developers, and the more advanced your problem the fewer people there are doing something similar;
b. The sheer size and scope of the SharePoint platform means there is lots of unexplored and undocumented territory, and every now and then you’ll search on some aspect of SharePoint and find zero hits online.
c. SharePoint rarely exists in a vacuum. There are always integration points and little quirks that are unique to the organization deploying the product. These often center around network irregularities, legacy systems, business processes, or cultural issues within the organization. Any of these points, and more, can throw wrenches into your solution.

So all these things add up to one thing: you’d better be really good at solving these issues, because there is often nowhere to turn if you can’t figure them out.

2. Have access to a SharePoint environment. And when I say “access”, I really mean a complete development farm over which you have full control. Having your own environment opens up the following opportunities:
a. The freedom to make mistakes. Software development is about “poking the box”, as Seth Godin would say. That is, you learn by trying new things, making mistakes, and drawing lessons and understanding from them. Having your own environment means you can make all the mistakes you need to, roll back and keep going.
b. Your own security sandbox. Security is an important aspect of SharePoint solutions, and you’ll need the ability to create accounts and alter the privileges of those accounts. Suppose you are building a workflow that routes to different users. Without the ability to create and use different accounts, how on earth are you going to test that workflow?

If your employer is trying to get you to learn SharePoint and they have not provided you a full SharePoint server to use, they are setting you up for an uphill and frustrating experience.

3. Get some real-world problems to solve. Real-life solutions in SharePoint are rarely as straightforward as training or demo scenarios would make it seem. It is managing those quirky idiosyncrasies peculiar to the customers’ way of doing business that separates the competent devs from the pretenders. Workflows, especially, tend to get very tricky when you try to automate real-world business processes. Hands-on labs are a great way to get introduced to a topic, but once you’ve done them, try to apply them to the way things would actually work in your environment.

4. Get to know SharePoint’s user interface really well. Smart SharePoint developers know to leverage the out-of-the-box capabilities of the platform as much as possible. This means having a firm grasp on how to use SharePoint’s various UI components properly. The Ribbon, the ECB, Site Actions, List Views, Forms, layouts pages, web parts – each of these components, and more, lend a unique aspect to the SharePoint ecosystem, and knowing when and where to deploy these items will pay off in a number of ways. For example, leveraging OOB components will simplify your development efforts and result in a more consistent experience for your users. Knowing this will also come in handy when practicing skill number 5….

5. Learn to do things the SharePoint way. SharePoint is a funny platform. In many ways it gives you a lot of freedom, but it will punish those who take too much of that freedom. I see this a lot with user interfaces. Sure, in theory you can build lots of custom web parts and user controls and layouts pages to build out your screens exactly how you want them. Just know that if you do this as a default approach you are exposing yourself to some risks:
a. You are building an unnecessarily complex solution, which will lead to bugs, maintenance overhead and place more burden on your administrators.
b. You are likely missing out on a great deal of out-of-the-box SharePoint functionality. For example, if you are building a custom solution to show a grid of data, you are losing the ECB, the Ribbon, and some nifty sorting and filtering functionality, not to mention the security trimming, which you’ll now have to manage yourself. A common List View provides all this and more, and can be quite flexible through customization.

Also included with this skill is knowing how to push back when requirements are out of line with SharePoint’s expectations. You’ll need to seize these opportunities to educate your customers on “the SharePoint Way”.

6. Find a mentor. Trying to learn SharePoint on your own is an uphill struggle, and when you hit a wall you need somewhere to turn for help. Blogs and MSDN will only get you so far, and much of the content you’ll find on the web is either not useful or downright wrong – until you figure out where to look and whom to trust. Having a mentor or a network of colleagues will be a major asset, and if you are lacking this you’ll want to look for a user group or at the very least an online community like stack exchange to bounce ideas and ask for help.

7. Learn the internals of SharePoint. While the first six traits I outlined were mostly non-technical in nature, the remaining skills will cover the technical aspects of the things a SharePoint developer needs to know. Foremost on that list is an understanding of the underpinnings of SharePoint. There is a lot to learn here, but most of it is found in the “hive”, or the file system location where SharePoint’s files live(this is known as the ’14 hive’ in SharePoint 2010). The 14 hive is a treasure trove of useful information, and by looking through it(on a development machine of course), one can learn a whole lot about how Microsoft builds things. Among the useful things you can browse in the hive include:
○ Features
○ Layout pages
○ JavaScript files
○ Site Definitions and Web Templates
○ XSLT files
○ Images
○ Configuration files
○ User controls
○ Resource files
○ Much, much more

An understanding of how SharePoint is put together will help you understand how to extend it, and will offer clues as to the right way to do things when you are stuck(which will be often).

8. Learn .NET. SharePoint heavily leverages .NET, and any non-trivial solution you build will likely involve some amount of .NET integration. Knowing how to code in .NET is crucial, of course, but of equal concern is knowing the internals of .NET. Deploying an assembly to a SharePoint farm is a complex process, and you must master the various ways to deploy and register assemblies, modify and troubleshoot configuration entries, and advanced debugging techniques.

9. Get to know the Windows Infrastructure ecosystem. I’ve said it before, SharePoint doesn’t exist all alone by itself. It is tightly integrated with several Windows products, and getting comfortable with SharePoint means getting cozy with these systems as well, including Windows Server, SQL Server, and IIS. You may optionally find yourself dealing with other players as well, including Exchange, SQL BI, and the Office client. A knowledge of WCF and Workflow Foundation will likely come into play at some point as well.

10. Build solutions, not customizations. Many people who call themselves SharePoint developers never launch Visual Studio. While it’s true you can build great solutions in a very short time without ever using Visual Studio, the benefits of that approach will diminish in the long run. These “customizations” are one-off solutions and cannot be repeated unless the work is re-done. Since there is no source code associated with these efforts, maintenance becomes a dicey affair, and when a solution is broken, there’s often no way to resurrect it.

A professional SharePoint developer will use Visual Studio to build a repeatable, deployable solution package which can be deployed and activated on a site. He will follow the same processes as a custom-code solution, with source control, testing, deployment, and support.