C H A P T E R  10

Intermission: The Mentality of a SharePoint Developer
Use Your Noodle the Right Way and Be a Better Developer

So far, we have focused on learning new technical skills. Our journey has taken us from site exploration boot camp through forests of lists, demons in dark caves, glaciers of content types, and fields of gold, all while keeping a goal in mind—that of understanding how SharePoint architecture works from a user experience perspective.

During the next part of this book, we will use a series of exercises to apply what we have learned to create a completely new SharePoint site, from the bottom pits of fields and up toward the surface of seeing our site in all its glory. There is plenty in store on that journey as well. Our new goal will be to create a publishing site for a newspaper with a completely new interface and experience for both the end users and the authors.

Before we start on that journey, however, I would like to take a short break here to share with you some of my thoughts on the mind-set of a SharePoint developer. There is little technical skill building here; it's just a short break to give our minds a little rest before we head on home. No screen shots, no code listings, no tables of reference—just you and me sitting down with a cup of coffee and talking about a developer's life.

Well, actually, I'm doing the talking, at least for the next few pages.

These ideas are just my personal opinions, and your opinions will vary. If you do not agree, good! Let me know so I can learn from you. Shoot off an email, hook up with me the next time we meet, or just write a blog post and curse my ancestors.

SharePoint Is a Platform, Not a Product

You may be starting to realize this now, but SharePoint is a lot more than team sites, meeting sites, publishing portals, and blogs. The site definitions that ship with SharePoint show off some of these features, but we have a wide range of other options.

In fact, many of the coolest features of SharePoint, such as content types and event handlers, are hardly used at all in the default setup. As such, many developers have no idea about the potential that SharePoint has and stick only to using the default and simple features that ship out of the box.

Sadly, this also means that very few people take the time to learn and practice more advanced development options, which in turn leads the community as a whole to shift toward simpler and simpler customization options. I have read from very prominent SharePoint community leaders that the best thing to do to deliver a great SharePoint experience is to just trust what Microsoft has created and adapt your customer to SharePoint and what is offered by default. “Fix some logos and some style sheets perhaps, but otherwise just use the default lists, libraries, pages, and workflows.”

If I were to put my disagreement with statements like that on a scale of 1 to 10, I believe the rest of this book would support the number on that scale. Suffice to say it would be far closer to infinity than 1.

I fear that the art of hard-core SharePoint development may become a rare commodity.

I am not saying you should create something from scratch just because you can. Share-Point ships with a lot of ready-to-use features that will greatly enhance any collaboration or publishing solution. There is no reason to create a document library from scratch if all you want to do is change a single library form. If the default QuickLaunch menu and top navigation bar fulfills 90 percent of your navigation requirements, you should consider carefully whether the last 10 percent is worth re-creating the remaining 90 percent. Perhaps that time is better spent on another part of the project.

Some good advice often heard is to know the default features (features as in the literal sense and not the SharePoint technical sense) and then base your customization on those default features.

The reason why I am stressing the need to be able to build features from scratch is that you should know very well how these features work. You never know what your next project will require from a customization perspective. If you have deep knowledge of a certain feature, you will likely see how you can utilize default features better and save a ton of time.

In short, know how to modify absolutely everything you can. And then don't.

To Boldly Go...

Learning is exploring. Don't be afraid to try something that doesn't work; there is no failure. Either you learn or you succeed.

When you are working with a virtual environment, you have a Save option that allows you to revert to a previous state at the click of a button. By taking regular snapshots of your virtual machine, especially before trying something risky, you lose very little time or effort if everything goes kaboom. Now, if only real life could be virtualized...I would go skydiving this instant.

Be adventurous; there is so much cool stuff to learn about SharePoint. Exploration is the key. Try stuff out, and eventually you will know how it works. It may take time and effort, but the kick you get from learning something completely new is well worth what you put into the adventure.

Don't be afraid of reflecting code; you can learn massive amounts of information by looking at Microsoft.SharePoint.dll. I often wander for hours inside DLLs just to find out more about a program or system. Put .NET Reflector on speed dial, and your understanding and confidence will rise with each launch.

Do all this from a learning perspective. When you hit the real world where you start putting all your skills into production systems, your development experience will change. You'll face source control, rigorous testing, code revisions, and a lot of other production development topics. However, you will know your SharePoint like you know the back of your hand.

This Time It's Personal

Another piece of advice is to look at what others have done before you, but rather than copying what they have done, learn from them. Try to put yourself into the mind of the girl or guy who wrote a piece of code. What was that person thinking? What particular style is used? Can you see similarities in other pieces of code?

Remember, every piece of code you see—every feature, every page, every workflow—was at some point designed and developed by someone, perhaps just like you. If you manage to think of code in that fashion, development becomes a much more personal art. No longer will you think that “Microsoft did this” or “Oracle wrote that” rather, you will begin to see the person sitting in some office somewhere on the globe with a task, just like you, of creating just that piece of code.

When you write code, consider your own style as well. You are an artist. You create code; you don't just produce solutions. Whether you are aware of this, you have a very particular style of writing code. Perhaps you picked up a pattern in an old book back in the ages, perhaps you are inspired by a particular blogger and mimic their style, or perhaps you just add up bits and pieces of code you find online.

Your code is not dead after you deploy it and wrap up the project. The code will remain for a very long time, and it carries your signature. Someone may at some point open your solution or reflect your assembly to see how you were thinking and try to understand what made you make a certain decision.

Think of the posterity of your code when writing, and consider the welfare of those who come after you.

Use the Right Tools

I know I have said I prefer that you use a nail, two wires, and a battery to magnetize your own hard disk plates. That is a joke. Feel free to laugh. If you don't, you seriously need to reconsider your approach to tools.

You can do quite a lot of fancy SharePoint development in Notepad, and doing so in some cases is the best thing. For the sake of productivity, however, consider learning about the different tools that can speed up your development time.

Learn how to create a feature (in the technical SharePoint sense, not the literal) by hand. Do so for your first five features just to add variety to your learning experience. After you have become a bit familiar with the authoring experience, switch to tools. Use WSPBuilder, VSeWSS, or STSDEV; find out what you like, save tons of time, and still have the experience required to debug a faulty elements file. Blow open a WSP solution file in WinZip, pull the bowels out, and put it back together. Create a .wsp file yourself, including all the solution manifests, features, and files you need. Then switch to a tool that does the job for you.

The problem is that starting out with tools will subtract from your learning. If all you want is to produce a solution, fine, but you will never learn what you are doing beyond “click here to create something.”

I will not recommend any particular tool, because finding out which tool works best for you is also a learning experience. My preferences are stated throughout this book, but you should not take these as any kind of best practices or even any endorsement of one tool over another.

Take solution building in Visual Studio. If you are using Visual Studio to develop Share-Point solutions, you have at least four good alternatives; using no helper tools, you have the Microsoft Visual Studio Extensions for WSS, STSDEV, and WSPBuilder. I have used all these tools and landed on my preference of WSPBuilder only after spending weeks finding out what fits my development style.

Your style will be different. Each tool has strengths and weaknesses, and you must find out what you like. There is no best or worst, only preference.

The Most Important Tool of All

OK, I'll reveal the biggest secret to SharePoint development I know. You may want to sit down, grab a cup of your favorite brew, relax, and try to prepare yourself.

The most important tool to SharePoint development is…

SharePoint.

That's right. SharePoint is a tool. Nothing more. Granted, it is a rather advanced tool, much more advanced than, say, a hammer, but it is still just a tool.

It doesn't matter how good you are with a hammer. You may be able to hit nails in your sleep with both hands tied behind your back and hanging upside down from your toes. All you are doing is striking nails into wood. That is useful, of course, but it will never get you a house.

If you want to build a house, you need to learn a ton of other skills. You need to learn design, architecture, and how to use other tools such as saws, screwdrivers, and blowtorches. As you probably realize by now, I have no idea how to build a house, but I know that you need far more than a hammer and a skilled nail barbarian.

So, try to see beyond SharePoint and see how SharePoint fits into the bigger picture. Teach your team, your boss, your customer, or whoever pays your salary how they can utilize your wonderful hammer-wielding talent. Show them how user experience, workflows, business intelligence, and all the other aspects of SharePoint development can bring peace and harmony to the world.

Don't be good at hammering. Be good at building houses, including being proficient with a hammer. Do that, and you have yourself a first-class ticket to job security nirvana for the rest of your natural life.

The Most Already!

OK, that's it! No more intermesso.