5 skills every SharePoint Developer should learn

So what makes a great SharePoint developer? I am betting there are a ton of answers, but I am leaning towards a short list of skills that every SharePoint developer should have.

5. Patience and sense of adventure

Let’s face it, if you are not going to stick with a career for more than three months you are dead from the beginning. SharePoint is not a ‘read this book to become a guru’. Granted, this does apply to most other technologies as well, if you do not plan to do some hard work to be good, chances are you will be stuck on the starting line of a marathon.

Be prepared to put some major effort into learning and do not be discouraged if you do not succeed immediately. You have months of great discoveries ahead of you, and my experience has been that the rewards far outweigh any effort I put into learning.

Not exactly a skill, but still an important virtue.

4. Workflows and business process automation

Businesses invest in SharePoint to either make or save money. One of the easiest ways to show customers how that money can be saved or made is to show Business Process Management. Workflows are such powerful tools that every SharePoint developer should have good understanding of what is possible.

My previous "Automating Business Processes in SharePoint" series can give you a good starting point:

Automating business processes in SharePoint: SharePoint Designer Workflows (Part 1 of 3)
Automating business processes in SharePoint: SharePoint Event Receivers (Part 2 of 3)
Automating business processes in SharePoint: Visual Studio Workflows (Part 3 of 3)

3.  SharePoint User Experience understanding

Your SharePoint solution may be as technically beautiful as Mona Lisa, but it will not matter a single bit unless your users can understand how to use the solution. Try to put yourself into the shoes, boots, or sandals of your users and try to interact with your solution. Can you imagine any better way to display and interact with information? Do you even know how to change the display of a form? Are your content types logically organized?

My upcoming book, Building the SharePoint User Experience, will address many of the technical issues. There is also a preview article series over at SharePoint Magazine.

However, technical knowledge will bring you only half the way. You still need to work with your users to understand how they think, what they expect. Have them draw up what they imagine as the perfect SharePoint user experience. Then your job will be to work with those ideas and create a solution that users understand can with which they enjoy working. If your users are not on board your solution will be less used and the value will diminish.

2. XML basic knowledge and CAML deep knowledge

If you are going to develop anything beyond simple Hello world web parts in SharePoint you need to work with CAML. Your best way to start out is to learn basic XML and then move on to reading all you can about CAML.

CAML, being an XML dialect, is so important it is a contender for first place, but I realize that there is one more important thing…

1. ASP.net skills to rival Rambo

Ok, I’ll admit, I have no idea how good Rambo is at ASP.net, but I think you get my point. As SharePoint is based so much upon ASP.net, being good at SharePoint means being good at ASP.net.

The more your work with SharePoint and the deeper your knowledge goes, the more you see how ASP.net runs in the veins of SharePoint. Learn ASP.net properly and understanding SharePoint will be a much simpler task.


Do you disagree? Are there more important skills you think should be on this list? Let me know…

Found this article valuable? Want to show your appreciation? Here are some options:

a) Click on the banners anywhere on the site to visit my blog's sponsors. They are all hand-picked and are selected based on providing great products and services to the SharePoint community.

b) Donate Bitcoins! I love Bitcoins, and you can donate if you'd like by clicking the button below.

c) Spread the word! Below, you should find links to sharing this article on your favorite social media sites. I'm an attention junkie, so sharing is caring in my book!

Pin It

“Building the SharePoint User Experience” book available for pre-order at Amazon

The Book is now available for pre-order from Amazon. At the time of this writing there isn’t that much information on the Amazon site, and I actually just found out they had put it up for pre-order at all. However, stop by the book blog at http://www.understandingsharepoint.com/userexperience and you’ll find a ton of more information.

So, what are you still hanging around for? Get over there and buy the damn thing! I’m not getting rich by you sitting here!

Pin It

Debugging tips for SharePoint developers – Solving “Unknown error occurred” and related problems

I spend some time helping the community by answering questions and suggesting solutions. Quite often people get the familiar SharePoint "unknown error occurred" message and get stuck for lack of further debugging information. Other times the log files or event logs provided by SharePoint are insufficient to help out.

SharePoint "Unknown Error Occurred"

The "Unknown Error Occurred" error is returned for a wide range of problems. It is just a generic error and without some more debugging information, finding the exact cause may be difficult.

Your first order of business is to check the log files. These are located in [12]\LOGS. Your best bet is to check the log file immediately after the unknown error occurred, the log file can fill up quite rapidly. If you are unable to check immediately, search the file for "Exception"; if the exception has been logged you will find it.

However, fairly often you might not see anything in the log files. That can be because your log sensitivity is not set high enough. You get very much control over this sensitivity level in SharePoint, but the default setting might not be sufficient in a development scenario.

Modifying logging level

To modify the logging level in SharePoint you need to go to Central administration->Operations and Diagnostic logging. your most important setting here, at least in this scenario, is the Event Throttling setting. What you are setting here is at what level errors are placed in the Windows Event Log and into the log files of SharePoint.

Note: The log files are referred to as the trace log.

You first decide which category of events you wish to modify. If you select All from the Category drop-down your changes will affect all categories. This is useful to shut up anything but what you want to see. For instance if you are having problems with workflow debugging in SharePoint you can set All categories to None in both event log and trace log files, hit Ok, and then go back to the diagnostic logging page to set Workflow Infrastructure to Verbose. By doing this your trace log files will only have Workflow related messages and should be a lot easier to investigate.

If you are uncertain to which category your error belongs, start with

The second thing you want to configure is the trace log. For development purposes you will likely have very different requirements than in a production system. While developing you expect rapid response and do not need to have hours or days of debugging information, while in a production environment that might be the exact opposite.

My recommended settings, which I actually stole from Andrew Connell in his ‘Be a better SharePoint developer through tools’ talk on TechEd US 2008, is to set a maximum of 5 logs, each holding a maximum of 5 minutes of log data.

Now that you have set more relevant logging settings, try provoking your error again and checking the trace log files. If you still do not see anything, fiddle with the different categories.

Improving the "Unexpected Error Occurred" experience

I have never understood this error. Why is an error more or less unexpected? I mean, if you are debugging, it is a good thing to be able to verify that changing a working piece of code will throw an error or exception, but how would SharePoint know which errors are unexpected?

You do have some options for getting more information when an unknown, or known error occurs. By enabling some debugging options in the web.config file of the web application you can get a full stack trace returned right on the error page when an error happens.

While this is fine in a development environment, setting these values in a production environment is not recommended.

With that caution in mind, here’s how you would enable debugging information in the web.config file of your SharePoint site:

  1. Open the web.config file, usually located in c:\InetPub\wwwroot\wss\VirtualDirectories\[portnumber]
  2. Find the element named customErrors and change the mode attribute to "Off"
  3. Find the SharePoint->SafeMode element and change the CallStack attribute to "true"

Now, rather than the meaningless "Unknown Error Occurred", the "Unexpected Error Occurred", or any other cryptic error message you get the full stack trace when something happens.

You can even set this to be the default setting for new SharePoint web applications by modifying the web.config in [12]\CONFIG directory. Be aware that modifying any file that ships with SharePoint, such as the default web.config file, is highly unsupported. Your development environment will be unsupported if you modify this file.

And now we can all laugh a bit and imagine that we care. Just never do this in your production environment, that environment should be supportable. I have yet to find any developer who has been worried abut supportability on their development environment, however.

SharePoint Log Viewer Feature

Another tip I ‘stole’ from AC is to install Scot Hillier’s Log Viewer Feature. Part of the magnificent SharePoint Features package at http://www.codeplex.com/features, SharePoint Log Viewer Feature is a simple add-on solution to your Central Administration Operations page. Upon installation and deployment of the LogViewer.wsp solution you get a new link on the operations page that leads to a useful log viewer.

To install the solution follow these steps:

  1. Download the logviewer.wsp from the link above
  2. From the command line in Windows, type
    [path to stsadm]\stsadm.exe -o addsolution -filename [path to logviewer.wsp]
    (replace brackets with your info)
  3. Deploy the solution through Central Administration->Operations->Solution Management
    still in the command line, type
    [path to stsadm]\stsadm.exe -o deploysolution -name logviewer.wsp -local

Now you should find a new link on the Operations page of Central administration leading to a new ULS log viewer page.


Just select what you want to see from the available logs and you get a much better presentation of the log information than from searching through the raw log data in notepad.

Even though this tool is extremely helpful in some cases, there are some drawbacks. You need to know to some degree what you are looking for. Unless you know to which category or severity your error belongs you will spend more time searching through information with the log viewer than without. To be honest, LogViewer is much more useful if you have some experience with debugging in SharePoint than if you are just starting out.

I hope this helps you to have a better SharePoint development debugging experience. As always, drop me a line if you have questions.


Pin It