Another Middle Tier Advocate Heard From: Where Can You Go to Be a Middle Tier Developer?
It’s always interesting to me what people decide to write to me about directly versus in forums or as comments here on my blog. Here’s one that I think is definitely of general interest that I got today. I’ve edited a little and scrubbed a few things out of it, as it’s clear that the sender wouldn’t want to be identifiable. (I did leave in the nice things that s/he said about me, though. C’mon, I’m only human!)
Your blog is fantastic! I consider you the number one source for all SPD development (or "customization" as I see some people have taken offense to pairing of the words SPD and development). Like yourself, I work heavily in this Middle Tier, using SharePoint Designer, DVWPs, JavaScript, and jQuery to provide a rich user experience. The general consensus on the Intertubes is that people like us are evil. I was starting to believe them, but then you published your Middle Tier Manifesto. Finally, someone to champion our efforts! I have used this white paper as basis for my argument of the need for SharePoint’s Middle Tier designers, developers, or whatever people want to call it. This leads me to my question: what kind of jobs are available for someone that considers themselves an expert Middle Tier designer?
[… ]
I feel the time has come for me to move into a role where I can use these new abilities, but every job posting I come across is either looking for someone strictly admin level (i.e. managing farms, creating new subsites, backups, etc) or is a developer (VB, C#, plus a ridiculous number of other languages not necessary in SharePoint). What advice or tips can you give a Middle Tier Designer such as myself?
Once again, thanks for all your great blog posts! You are a true asset to the SP community.
One of the things I want to help change is this vast misperception that development in the Middle Tier can’t create real solutions of value. There is a tremendous amount of excellent work being done in the Middle Tier every day in many, many places. (There’s also horrible work being done in the Middle Tier *and* in Visual Studio. I’ll say it again: Tools don’t kill SharePoint; bad developers do.)
So where can you go to be a rad Middle Tier developer? Somewhere that is progressive and realizes that big budgets aren’t a sign of success. If you want to be a Middle Tier developer, you need to be able to convince people of the benefits and show them examples. Offer a challenge: Give me and a .NET developer a problem and let’s see how the two of us solve it. Then let’s see which solution stands up better.
The term ‘SharePoint Developer’ has been a misnomer for a long time now. We can’t have a movement around this without doing some work. Get out there and convince people!
So what do *you* think? What’s your advice for this brave soul?
Marc,
Perhaps you could create a ‘Middle Tier Team’ – SPMTT ! You’d be Hannibal of course.
A good starting point might be SPTechCon in Boston or the SharePoint Saturday in Tampa.
It’s a tough sell when you can’t get your foot in the door. RAD vs TRAD !
“One of the things I want to help change is this vast misperception that development in the Middle Tier can’t create real solutions of value. There is a tremendous amount of excellent work being done in the Middle Tier every day in many, many places”
Let me preference my comments that the discussion from my perspective had nothing to do with doing configuration, customization, and development via the UI or SharePoint Designer which is we’ll received by the community and market. Mark Miller has a site completely dedicated to this area.
What I see is some buzz about your use of the term “Middle Tier”. If you check authoritative sites such as Wikipedia (http://en.wikipedia.org/wiki/Multitier_architecture) and MSDN (http://msdn.microsoft.com/en-us/library/aa738757.aspx) you’ll see that there is a definitive use of the term. Trying to alter it, or repurpose it to discussion solution development on the SharePoint platform is confusing.
“The general consensus on the Intertubes is that people like us are evil…. Finally, someone to champion our efforts”
I never heard those words used. People like Laura Rogers make a living out of it and other passionate enough to dedicate a community to it like Mark Miller.
“I feel the time has come for me to move into a role where I can use these new abilities, but every job posting I come across is either looking for someone strictly admin level (i.e. managing farms, creating new subsites, backups, etc) or is a developer (VB, C#, plus a ridiculous number of other languages not necessary in SharePoint). What advice or tips can you give a Middle Tier Designer such as myself?”
This is because the market does not always understand what they need. Add a non-technical recruiter to the mix and seeing a quality SharePoint requirement is even less likely. The chances of finding a SharePoint Designer is virtually impossible (http://www.indeed.com/jobs?q=sharepoint+designer)
“Somewhere that is progressive and realizes that big budgets aren’t a sign of success. If you want to be a Middle Tier developer, you need to be able to convince people of the benefits and show them examples. Offer a challenge: Give me and a .NET developer a problem and let’s see how the two of us solve it. Then let’s see which solution stands up better.”
I feel a shift in the discussion here. I agree that there is a place for skills that lay between the Administrator and a Software Engineer; I do not however follow your thinking about solution development. I agree that technical SharePoint Admin could produce a better solution then a .Net Software Engineer new to SharePoint (I mentor many of them). All things being relative a SharePoint Solution Developer should have Administration and Designer skills that allow them to know when to use a blend of Configuration, Customizations, and Code via UI, Designer, and Visual Studio.
Steven,
We definitely need to come up with a name people that work at the Designer level.
To Marc’s comment:
“If you want to be a Middle Tier developer, you need to be able to convince people of the benefits and show them examples. Offer a challenge: Give me and a .NET developer a problem and let’s see how the two of us solve it. Then let’s see which solution stands up better.”
This does make sense, but I think it would be very hard to go into a job interview for someone looking for a developer, and then blindside them with this. Is the only way for SPD guys to get jobs is by networking at SP events? The formal avenues for jobs don’t seem to recognize us as seperate entity from the others.
Has anyone ever gotten hired for a SPD-centric position through standard means?
Kevin:
While blindsiding interviewers certainly sounds fun, it wasn’t really what I was suggesting. ;-) The problem is that many hiring managers think that there is one answer to a job opening for a “SharePoint Developer” and that is a .NET person. You and I can’t change that person’s mind very easily. I agree that the “formal avenues” see it that way. I think some of this comes from Microsoft and the way they market SharePoint. They also push the “.NET solves everything ” message. Well, .NET may solve many things (some better than others) but that doesn’t mean there aren’t other approaches available.
It’s even hard at the SharePoint events. I know that people think that a lot of what I do is sorta “cute”. Maybe its cute, but it always solves a business problem, or else I wouldn’t be doing it. That’s the message: Middle Tier development can solve business problems well.
So, no, I don’t think that one person trying to get an interview is going to change things, unfortunately. That’s why I’m trying to make some noise.
M.
My opinion might be slightly biased because of the environment I work in. As a whole, I agree with Marc’s concept of the “Middle Tier” regardless of what it is called. Unfortunately I work in an environment where we are not allowed to use Sharepoint Designer on a production network. Our policy states that we must build our solutions as .wsp packages and that is the only way we can deploy to Sharepoint. However, I know that a fair amount of what I do could be done using Designer and it might be faster but not really worth it in the end because of our policy. With that said, I agree that there are those folks that could give a hoot about .Net and can develop nice solutions in Designer. I also believe that I can develop nice solutions in .Net. The main thing I see is that there are three types of Sharepoint “Engineers” as I like to call them. I also like to classify them along the lines of the 3 main types of degrees. Associate: Someone who is familiar with the UI and basic nuts and bolts and can build simple but effective solutions with just the UI. Bachelor: Someone who can then add the power of Sharepoint Designer to really jazz things up a bit and add a lot more to the mix. These two are both limited to what you can do with the UI and designer and no matter what there is a limit. There is also a time based issue here that I will touch on in a minute. The third of course is the Master: Someone who can do the other two but also can develop custom code to go above and beyond the limitations of the standard tools and create full solutions that you can not do in the UI or Designer alone. Sometimes it takes a long time to write custom code and sometimes it is faster. Now, it seems to me that employers are always going to ask for the user with the most skill level or the Master as I called it. As someone else said however, sometimes you do not need that type of person as it really depends on your environment and what you are trying to accomplish. I actually enjoy all three types of Sharepoint “Engineering” and it is my job to figure out which of the 3 types of solutions will get the job done. I think that other than employers not really knowing who to hire, those that really do have to make a choice. If they can only hire one person to do the work, which of the 3 should they choose? More often they are going to choose the Master, but it would be nice to see a change in that mentality.
spevilgenius,
I always thought of the three levels as separate from each other. I’ve met some .Net level developers who don’t know too much about using Designer or DVWPS , and I’ve also met some Designer level folks who don’t know a thing about the administration side.
I’d rather see the three tiers/levels/disciplines blend and blur more. We have a portfolio of options we can use to solve problems, and we each need to know when each option is the best one. (I’m am *not* saying that the Middle Tier is the only game in town.) When something is do-able through the UI, no one should write any code. The easiest and cheapest answer *can* be the right answer, but it has to fit into the overall architecture as well as the collaboration strategy for the organization.
Too often we rely on “architects” for this decision-making, but I’d like to see more plain old “developers” understand what their options are so that they can contribute to the process. To whit, my teaching at the USPJ Academy.
M.