What is a SharePoint Developer Profile

I have a development team specializing in ASP.NET. Thus, the solutions we offer are based on the Internet, run on IIS, and use an MS SQL server. Everything on the company's intranet. The team has this experience and they are excellent in C # and .Net in general.

The company is deploying SharePoint MOSS 2007. This deployment is part of a project that I am not involved in and for which I have very little information. However, I know that they have created a layer of “thinkers” (those who will say what to do), the level of integration (who will configure, deploy and manage production) and that they need to establish the so-called level of development (those who will do what that the other two cannot).

I am asked to evaluate the opportunity to enhance my team's experience by adding the development of SharePoint. This is the easy part, I just need to find the necessary training and send my people.

However, today the development of a word can mean many things, and sometimes I find that configuration is used instead of development. I have no objections to develop the team, developing a new experience, but I want to be sure that all this stimulates my developers. Secondly, I do not want to say that we have experience in developing SharePoint, and in fact we are just modifying css or xml files. Also, I don't think that using wizards to create a solution is the best way to click on a C # developer.

The questions I ask myself first are what are the foundation of a SharePoint developer. how could .Net developers feel if they were asked to become SharePoint developers?

Any thoughts would be greatly appreciated.

+6
sharepoint
source share
7 answers

I started Sharepoint over a year ago when I inherited WSS 3.0 from my company.

Personally, I think that it was a great step for me to learn a little about Sharepoint development, there are many problems (for example, security, load balance, halo), it was nice to see how the WSS team was solved and helps me solve problems in others the solutions I'm working on. But I don’t work on WSS solutions full time, so others have to be responsible for how it works with WSS every day.

WSS and Sharepoint are extensions on the ASP.NET platform, so any experience with ASP.NET and .NET in general should be a good foundation for the developer who begins to create SharePoint solutions. I read the Inside Microsoft Windows Sharepoint Services 3.0 book to get the basic concepts and solution for wss solutions before I started working on WSS projects.

I quickly discovered that you must have a virtual machine environment to develop Sharepoint, because it is a pain working on the client and binding to a remote process on the server to go into debug mode. Therefore, I recommend creating a MOSS virtual machine with Visual Studio installed, with access to your version control system. Develop solutions on this machine, and then finish, then check the source control.

I also recommend looking at development tools such as stsdev and wspbuilder to help you build your solution, this will make the development process a little easier for you. The Internet also has many tools, for example. codeplex to help you.

Sometimes it can be a problem to develop these solutions, changes may require reusing the IIS pool or IISReset with brute force, error messages can sometimes be a little cryptic, and so on. But you will quickly catch and know where to look. Sharepoint also helps you a lot, I had millions of questions from clients that can be resolved using standard external web parts, so I don’t need to code the code to support the clients :)

Sharepoint also expects solutions to be encoded in a certain way, for example. 12, so it helps you standardize your decisions.

There is a serious lack of documentation, so you need to rely on Reflector and such tools a lot, just to find out what is happening within the framework, I hope everything will get better from 2010.

The initial learning curve is high, and many new concepts are learning technologies, for example. Workflows in sharepoint, featuers, ghosting, and code access modes There are many Xml configurations that sharepoint uses that developers should learn, including site definition, list templates, and more. There are sometimes days when I am stuck in Xml editing mode and cannot understand why things do not work, how they should do

These are just some of my thoughts, I worked mainly in the development of WSS, and it would be great if someone could comment on setting up web parts in Sharepoint, for example. search setting. This is what I did not do much.

+16
source share

From what I heard, SharePoint is a popular technology from a client point of view, but it is an object of hatred among developers.

+6
source share

It’s good to see that you noticed that Dev and Admin are being used “incorrectly”.

Although development for SharePoint can only be such as developing web pages, etc., I highly recommend that you and your team deal with deploying, installing, and configuring SharePoint. I am fully certified by SharePoint (WSS Config / Dev and MOSS Config / Dev), and knowing both ends was invaluable to me.

Knowing what is configured, where debugging and troubleshooting along the way will help. I suggest taking MCTS WSS 3.0 Coffuration training and / or MOSS Config training for at least 1 or 2 of your employees. The rest of the team will pick up the necessary things when they pass, having these two certified colleagues who will go to the guys regarding the config and the administrator.

IMHO, as a sharepoint consultant, implies knowing how to create part of the functionality as a developer, and then the ability to deploy, configure and maintain this functionality as an administrator (or at least an informed end-user / powerful user).

+5
source share

My colleague is studying SharePoint at the moment. Laugh at him all the time. Often he chats something like "wtf is this ?? !!". And then I feel a little sad because I know - there is a chance that I will have to study this material too (I think it’s not so easy to get projects).

I see this more as a tweak and tweak than a software development (a bit of a tick for hunting for 3 days in a row). You pick up some clay through these crazy sharepoint designers, and then endlessly tweak it.

For everything that I already know, there is a new name (i.e. spGridView) and unexpected behavior below.

The html that gets the rendering is bizzare (tables and a bunch of serialized viewstate everywhere).

But these xml`s configurations ... o_0
Now that I can’t overcome the obstacles. Even the hardcore SQL material is starting to seem like a child’s game.

Maybe I'm wrong, but as I heard Microsoft developed “spatial columns” (let me increase the number of columns for tables over a thousand) for sql, mainly because of Sharepoint. It scares me.

Of course, my opinion is HIGHLY subjective and a little offensive. But I hope this helps to better understand what I think and feel about Sharepoint.

We hope that the developers you work with see that they are different.


In short:
Not. I would not want to become a sharepoint developer.


Edit:
I could handle this initial difficulty. But the main reason that I don’t want is that I don’t think Sharepoint development is the right way. I mean, lately people have been discussing that web forms provide too much abstraction. Then what about Sharepoint?

+2
source share

Albert, look at this other thread called Whether the sharepoint developer is technically “equipped” to create his own applications and vise-versa . There is quite a lot of information on what is associated with the transition from pure .NET to SharePoint.

+2
source share

To be a successful SharePoint developer, you must have a high threshold for Buddha’s pain and patience.

+1
source share

Thanks to everyone for the answers, they are all very helpful.

from what I read here, I see two things to consider.

Firstly, this is the context of use, which, in my opinion, is an important factor. In some places in SharePoint, “development” can go very far and can include developing really interesting things to meet the needs of new customers. this may be related to writing code and so on. And in some other places, it can be just administration and configuration to support already installed solutions.

Secondly, this is personal motivation. It really depends on the person. Some .Net developers with good experience prefer not to go in a direction where they will not encode the "SharePoint path", and would like to write code in C # or in some other languages. However, there will be others who choose this path and will be happy to have such a career. They will be motivated and therefore offer truly enjoyable solutions.

For example, from my personal point of view, and if I had remained in development and programming, I would not have chosen SharePoint development using high-level wizards and menus as a way of progress in my career. Despite the fact that I do not do it these days, I still like coding, compilation, debugging, etc., but it's just me.

0
source share

All Articles