So you want to become a SharePoint professional and have come to one of the most tricky questions to answer: What is a SharePoint developer?
Actually, the question is rather easy to answer, once you have some common and basic understanding of what SharePoint development entails.
What Is a SharePoint Developer?
If you look at the term, and throw away any personal feelings for what you think words should mean, then it becomes quite clear what a SharePoint developer is. Let me illustrate.
If you want to get your hair dressed, you go to a hair dresser, and from that we can assume that a hair dresser dresses hair. If you want something baked, you go to a baker (or your local medical marijuana outlet, but that’s for another blog), so a baker is someone who bakes. If you want to get something moved, you hire a mover, and a mover is thus someone who moves.
Now, if you want to get something developed on SharePoint, what could we possibly call the person that does that task? You should get this right on the first try; we call them a SharePoint developer.
Another commonality between the hair dresser, the baker, and the driver, is that you are rarely interested in the tools they user to perform their task. You don’t say to a baker that you only want to buy his bread if it’s made with a specific stand mixer. You usually aren’t interested in the brand of scissors your hair dresser users, and the lifting support the movers use, well, as long as they get that piano up the stairs, you don’t really care, do you?
And even if you are interested and specific about the tools used for whatever valid or invalid reason, you’ll still call them bakers, hair dressers, and movers, even if they user different tools. The reason for this is that their job titles describe the tasks they perform, not the tools they use. You don’t have KitchenAid bakers or a Shiro hair dressers (yes, I had to Google that). You may have a heavy items mover, but you would still call other people who move things movers, even if they don’t have specializations in moving heavy items.
So, a SharePoint developer develops in SharePoint, as simple as that. If, or rather when, you start picking up the conversations that have been ongoing for years in the community about whether people using specific tools are allowed to call themselves developers, well, ignore them and think about what makes sense.
The first duty of any SharePoint developer is to solve business problems. As long as you do that, and you do so in a professional manner, the tools you use or the title you put on your business card is largely irrelevant. If you think that the term developer is too ambiguous, and honestly, even the SharePoint community cannot really agree on what it means, then feel free to call yourself whatever you want.
By solving business problems, I mean that your first focus isn’t necessarily to work with a business owner or client, but that the ultimate goal of your solutions is to cater to the needs of the business. Many developers may never see much less talk to an end user or business owner, but SharePoint is a business platform first and foremost.
However, SharePoint development is a complex profession. In fact, it’s not even a profession, it is a class of professions that to some extent are defined by the tools they use.
SharePoint Developer Tiers
In broad terms, you can categorize SharePoint development methods into three tiers.
Note: This tier division is the brain child of luminary Marc D. Anderson, detailed in his Middle-Tier Manifesto.
The first tier deals with development using the web interface and client software only. First tier developers utilize the web interface to build taxonomies for business objects, create user experiences using web parts and maybe a few simple pre-made scripts, installs and configures Apps and Sandbox solutions, builds information panels for Office, and so on. First tier developers benefit from the most rapid development methods at the expense of freedom and power.
The middle tier of SharePoint development starts utilizing specialized tools and uses scripting and markup to develop solutions. Typical tools are SharePoint Designer, InfoPath, and maybe Visual Studio for script development. Middle tier development produces more flexible and customizable solutions than is the case for the first tier, and middle tier developers have more freedom and power at the expense of having to do a lot more work and be somewhat limited in terms of solution portability.
The third tier developer focus solely or mainly on developing WSP solution files and managed code solutions using tools such as Visual Studio and extensions such as WSPBuilder, VS Tools for SharePoint, and STSDev. Third tier development offers the greatest degree of freedom and options and also gives developers the most power of all the tiers. However, this comes at a price, of having to build all the ‘bits’ they need and also of needing the discipline to harness all that power.
What is important to know is that these tiers are not mutually exclusive. Although most seasoned SharePoint developers spend most of their time in one of the tiers, they also utilize the other tiers when required. A middle-tier developer may build a prototype for a solution taxonomy before building a web part in SharePoint Designer to display or manage that taxonomy. A first tier developer may utilize SharePoint Designer to modify or create scripts or style sheets to build their sites, and a third tier developer will more often than not start a project by prototyping the solution in the first tier.
What is absolutely critical to know, however, is that none of these tiers are better or worse, nor that developers that specialize in any of the tiers are better than the developers of other tiers. What matters to your skill level is what development skills you have, not the tools you use. Any SharePoint developer regardless of favorite tier will need skills and understanding of development topics such as source control, debugging, data modeling, event handling, security, and so on. Tools are there to make these tasks easier, not to save you from having to know these topics.
Also not that the developer tiers is a broad categorization. Once you get familiar with each tier, you will likely want to focus even more. For example, first tier developers may specialize in taxonomy or client applications, middle tier developers may specialize in InfoPath or DataView web parts, and third tier developers may specialize in workflow or web part development.
How To Become a SharePoint Developer
Regardless of what type of SharePoint developer you want to become, you need a good understanding of what SharePoint is and what problems it solves. If you are using SharePoint in your job, for example, you may want to start exploring the possibilities that exist. Ask whoever is responsible for SharePoint (or ask a mirror if it is you) to give you a site collection in which you can experiment.
Start going through the list and library types available to get an idea of the tasks SharePoint can handle. Explore the existing web parts, look up the site and site collection features, explore the permissions model, and so on. In short, play with it to see what it can do beyond what you already do.
Note: There are plenty of resources available to learn SharePoint, but rather than recommend any specific resource, I encourage you to start practicing your Google skills and find the resources that make sense for you.
When you decide to start your SharePoint development career, focus on learning the tools and methods in which you have prior experience. You should already be well versed in using SharePoint and understanding its capabilities, and if you have no other development experience, this is a great starting point for first tier development.
If you have prior programming experience, defined as building compiled code in some form, then the third tier will likely give you the most familiar starting point. You’ll need to get Visual Studio, and you need to start learning the SharePoint object models (server and client-side, so no cheating). Further, if you don’t already dream in XML, you haven’t used it enough.
Note: Beyond XML, your language and tool choice in the third tier is largely up to you. In fact, you can build third tier solutions using Notepad if that’s your fancy.
Since I’m the one writing this, let me modestly take this chance to blatantly promote my own book on learning third tier development, Beginning SharePoint Development, as a great resource to get you up and running. You can pick it up from http://uspjournal.com/issues/beginning-sharepoint-development/. In fact, all of my USP Journal issues will help you become a better SharePoint developer.
SharePoint Developer Myths Debunked
As your development career moves along, you’re bound to come upon many myths that may or may not sound plausible. Let me wrap up this article by debunking some of them.
First, SharePoint development is not harder or easier than developing on any other platform. You’ll find plenty of statements from developers saying that development on SharePoint is too hard. The fact is that the hard part isn’t any harder in SharePoint than it is on other platforms. Like any other platform, SharePoint has its bad and good sides. Any task you know is easy and any task you don’t know seems hard, at least when you get beyond the “how hard can it be” stage.
Second, a SharePoint developer does not have to do compiled code programming. One of the most common myths is that to be allowed to call yourself a developer, you need to be a programmer of compiled code. See the initial sections of this article for an explanation of why this is bollocks. If you develop, you’re a developer. If you bake, you’re a baker. If you move, you’re a mover. If you dress hair, drive, build, paint… Well, you get the picture.
Third, third tier SharePoint development is not your last resort. You’ll also quickly find a plethora of claims that building third tier solutions should be your absolute last resort, after trying everything else, including prayer. The arguments are often that third tier solutions are difficult to maintain and upgrade. The fact is that well-built SharePoint solutions not only upgrade excellently, but can actually work across SharePoint versions, making upgrades easier than for other development tiers. Note the emphasis on well-built.
Finally, no SharePoint developer is an expert in all SharePoint development tasks. SharePoint is a complex mistress, and its developers need to focus to satisfy her needs. The less you focus, the less you become good. Each development tier takes years to master. If someone say they are experts in more than one or two tiers, they are probably just experts in pulling your leg, or they’re just plain ignorant.
Note: The same applies to recruiters. A clear sign of a recruiter who has no idea about how to find SharePoint developers is one that looks for experts in multiple tiers or even specializations.
Final Thoughts and a Warning
A SharePoint developer is a resource to any organization, and a career in SharePoint development can yield both material benefits and great personal rewards. At the time of this writing there is a great shortage of skilled SharePoint developers and since a SharePoint developer’s first duty is to solve business problems, as long as businesses have problems, you’ll have a job.
In fact, take this as a warning. Right now, you can get a job as a SharePoint developer if you manage to spell SharePoint correctly.
However, having a job is a far stretch from being an expert. Don’t expect to quickly become a SharePoint developer expert simply because you can rapidly churn out solutions that impress your boss. Any skill in which you want to become an expert requires you to focus and dedicate considerable time to both learn and practice.
Before you develop these considerable skills, remember that what you are doing is ultimately what the business will use to remain profitable. Your failures or lack of skill may cost the company much in terms of lost efficiency or revenue, or cost employees their jobs. Start with what you know, practice before you go into production, and make sure you learn the basic skills of software development.
This isn’t unique for SharePoint, though, so take it as general advice. Expect to spend thousands of hours increasing your skill if you want to become an expert SharePoint developer.
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!