Laura Rogers, You Are NOT a Developer – But Maybe You Should Be…

OK, this isn’t really another @wonderlaura post, but since Kerri Abraham posted her article today, I thought I should follow up and post my opinion.

And although this does apply to ‘people like Laura’ it isn’t specific to her. Frankly, I have no idea what she does, how she does it, or how it works for her. It may or may not work, and she may or may not be good at what she delivers; I don’t know.

However, there is a key point here, in that Laura Rogers claims she is not a developer. What she does, though, is claim she is not a developer for the wrong reasons.

Kerri is very right in saying that Laura Rogers is a developer – because if you are developing something, regardless of tools, you are a developer. You may not be a programmer, which is something completely different, but you are a developer. So is Mark Miller, by the way. In fact, he developed from scratch.

You get my point.

So, Laura Rogers is a Developer?

The issue I have, though, is the ease with which people become developers these days. You see, I don’t become a surgeon simply because scalpels are now easily available on the interwebs. I don’t even become a surgeon if I use a scalpel to cut someone’s belly open.

“Look, how easy it is to do surgery, and no medicine required!”

I would not accept that. I don’t care what tools a surgeon uses. What I do expect, though, is that when they decide what tool to use, and I fully trust their judgment on what tools to use, they know not only how to wield it but how it will affect every part of me. I expect the surgeon to have a thorough medical understanding, not to be solely a blade-wielder. If all they had was insane cutting skills, the best this side of the North Pole, I still wouldn’t trust them to cut me open.

When experts like Laura goes out and say that ‘avoid surgery unless it is the last resort’ that doesn’t make sense to me, especially considering they usually lack the understanding of what that surgery entails. As a patient, I want my GP to know what makes sense, or send me to an expert if he or she does not fully understand the problem. I don’t want them to dish our advice on something completely foreign to them, simply because they’re not trained surgeons themselves. Of course you don’t hand out dates with the OR in every case, but saying it should be avoided is simply retarded. If surgery makes sense, then tear this shirt off me and start dissecting.

So, Laura Rogers is Still a Developer?

Well, I still don’t know about her, but I know that I’m a developer. I know that because over the previous 30 years or so (it’s actually closer to 27 since I first started programming) I have dedicated myself to building things on computers. I have the formal and the informal training. I’ve aced the data modeling classes. I did source control before VSS was even an abbreviation. I know at least five quotes from Donald by heart, and yes, I know whom a developer would mean if they just said Donald. And no, it isn’t Disney.

What that means is that when I develop something, I think about security, maintainability, about possible misuses, about preserving the code and code history, about how my solutions can be extended by ideas nobody has had yet, about making the data and systems efficient, not only from a human perspective, but from that of a computer, or even the system itself. I see a loop, and immediately I get a cold shiver, and then I think of three different ways to monitor the loop, and about every possible input parameter that may or may not affect the loop. I see states of machines, not state machines. When I know a user will affect my system, I put ten failsafe measures in place, just in case the user circumvents the first seven  and I make an assumption in the next two and fuck everything up.

One thing I don’t do is wield blades. Or rather, I may, but that’s usually just to show off.

But, do you know what? I’m not in any way unique. This is what we, as developers, do. Or should do. That’s what we spent years of lost dating in our youth learning. When someone talks to me about “high school sweet hearts” I’m immediately thinking candy.

Does Laura Rogers Do All That?

Frankly, I still have no idea what Laura does or doesn’t do. She may or may not be the world’s greatest developer. This isn’t about her, it is about the attitude that by simply saying that you’re not a developer, that somehow removes the responsibility of making developer decisions, in every single choice.

Hey, we can do all this cool stuff with workflow, so now we can build (not develop) our own solutions and because we’re not developers, we can simply shrug our shoulders when someone asks how we’ve tested our solution, or how we’ve ensured that our code exists in a repository.

And this isn’t even about documentation, or governance, as Kerri pointed out in her article. It doesn’t matter if you write down the angles you used to cut someone open. If you have no idea how to cut, you see only what you think should be the result, with no understanding of the steps required to get there.

Most people who do development on SharePoint simply start cutting, thinking that as long as the result looks like they imagined, it must have been done right. However, doing development tasks does not make you a developer, any more than doing surgeon tasks makes you a surgeon.

So, here’s my advice.

  1. Own the “developer” badge with pride, but understand what it entails. If you can’t afford the years of formal training or decades of self-taught hacking, ask a developer to guide you, or at least sit down with them to understand how they think.
  2. Skip the “as long as I don’t write .NET code, I’m not a developer” attitude. If you develop, you are a developer. I’m a developer, even if all I do is makecab a ton of XML files into a WSP. That includes the full responsibility package.
  3. Understand that we (the developers) haven’t spent all the time we have learning this stuff, simply because we didn’t want to date during high school.

When tools become as easily available as they are in SharePoint, everyone can wield blades. It does not make them surgeons, but it does make them damn dangerous.


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

Published by

Bjørn Furuknap

I previously did SharePoint. These days, I try new things to see where I can find the passion. If you have great ideas, cool projects, or is in general an awesome person, get in touch and we might find out together.

8 thoughts on “Laura Rogers, You Are NOT a Developer – But Maybe You Should Be…”

  1. And the very point of my article Bjørn was in stating what you’ve said here, but to reinforce the fact that we aren’t dangerous as long as we document and follow some method of development that allows for oversight in a controlled and learning atmosphere. Your post here completely undermines that notion, since you have highlighted the risks and not even mentioned that there are ways to mitigate them (through documentation and governance) that would give users more freedoms with these tools.

    To equate SPD with a surgeon’s scalpel is an extreme that is ridiculous, but if we are to use that as an example, then we would also illustrate that my examples of using SPD in a test environment would be like a surgeon learning surgery on a cadaver, documentation being the test that proves the surgeon is ready to wield the scalpel on a live subject and the community being the university from which we learn the technique.

    I have a hard time believing that you of all people would write something as damaging to a person’s freedoms as this post. Restricting SPD is an antiquated practice that should be reversed, your post only givesIT the fuel they need to keep users locked down and I’m very disappointed in the message you have sent.

    1. Kerri:

      Limiting users is quite often a necessity when users believe that what they can do, they should do. The result, far more often than I’d like to admit, is that users dig themselves so deep that they have no way of getting out again, and it the process often ends up stalling the organization too.

      There’s no equation to testing with documentation; it’s not about documentation at all, it is about accepting that development, whether you do so through the web interface, in the middle tier, or in Visual Studio requires extensive training and knowledge. How would you, for example, protect against a script injection attack in your data view web parts? How do you sanitize your URL parameters when using query string filtering? These are vital tasks, potentially putting the entire organization at risk, but we simply ignore it, trusting that “if it were that dangerous, Microsoft wouldn’t let us do it”.

      IT’s only fuel is limitation. Your boss won’t pay for training, and your employees won’t walk the miles required to gain the skills on their own dime and time. The result is that the only other professional entity with the required skills, your IT operations department, need to do the only thing they can, namely to shut you up.

      That said, most IT departments wouldn’t know the up and down of a URL parameter, far less know anything about any kind of injection. They have only one weapon, though, and their task is to defend the IT infrastructure.

      If you, or people like you, would take the friggin time to learn what IT needed to safely grant you the permissions you need, then it would be fine, but you can’t be bothered or it won’t make business sense. If your boss would grant IT the learning time and resources required to learn to operate an environment where ‘power users’ (I hate that term) can run wild, then it would be fine, but we both know your boss isn’t going to allow that. And no, that wouldn’t make business sense either.

      Before you argue with the ‘running wild’ statement, saying that you’re not going to run wild, just do a few things here and there, well, unless you know the consequences of your actions and your changes then for all intents and purposes there’s no difference between a pellet gun and a nuclear bomb.

      So yeah, I see serious problems for SharePoint. The utopia won’t happen any sooner for SharePoint than it was for Access, when everyone suddenly turned database developer overnight, knowing just as much about normalization as I know about cross stich knitting, or whatever it’s called…


  2. Bjørn this is the rationale used to run police states. Considering SharePoint is a collaborative system, this is about as uncollaborative an approach as I could imagine and its precisely this sort of thinking that gives IT such a bad reputation and has buinesses look longingly (and naively) into the cloud to escape it. Given that stakeholder buy-in is such a critical factor, and given SharePoint is to this day, put in to solve no actual clearly articulated problem, this sort of thinking/action will seriously undermine the long term success of a SharePoint initiative.

    But the issue you highlight is real, has risk and needs to be addressed. That is: people understanding the consequences of their actions. Now I have lived the nighmare of that dreaded 2am call, to recover a dead system that I had no part in putting in, with the pressure of an entire company breathing down my neck to recover it. So I totally get this view – but ultimately the legacy you will create will only exacerbate what organisations are trying to get away from…

    True SharePoint governance (and I mean the real deal… not freakin encyclopedia sized reams of technical documentation and complex processes with tight restrictions) – deals precisely with this issue. In my opinion if you do not raise this issue and allow stakeholders to decide how to deal with it collectively *in light of the purpose of SharePoint*, then you are not governing, you are totally focused on the means of SharePoint and not the ends that it was put in for.

    So I find it untenable that anyone can start with such a “thou shalt not” approach before people understand what difference SharePoint is going to make. Once you know that difference, you can at least be in an informed enough position to make a call on this, and other issues


  3. Although I regret the tone of the conversation (a bit)… (but enjoy the humorous statements of .b 🙂 ), I must agree with .b

    SharePoint is a complex platform, any which way you like at it. Without training and knowledge, people using SPD can ‘run wild’ and hurt your SharePoint environment in more ways than you could ever imagine, because they don’t have a thorough understanding of the complexity. Without that proper training, people shouldn’t be allowed to use that kind of tooling (just like someone without medical training using a scalpel…).

    SPD is in every aspect a development tool. It’s not just about changing font color. It’s about masterpages and page-layouts, workflows, content types, etc. If you educate your users to the level they CAN use SPD responsible, then they’re not ‘powerusers’ anymore, they have become developers…

    Maybe some day, SharePoint and SPD will become a combination that non-developers can use without the risk of really screwing things up, but we’re not there yet. Not even close…

    And giving non-developers tooling like SPD, just to ‘force’ that Utopia, is just plain silly and irresponsable.

  4. I hate to leave another comment here only because I don’t want to give Bjorn’s post any more momentum that it has already seen because I feel it is so very damaging to those of us trying to move forward in a career with SharePoint only to be held back my single-minded IT policy that can’t recognize that business users are perfectly capable of fully understanding a tool like SPD without a degree to do so – again, I state that equating SharePoint Designer with a scalpel is extreme, but I do recognize there is some degree of danger which was why I wrote my original post(s) from the beginning

    And since it is not linked in here I think it should be:

    I do not think power users should ‘run wild’nor do I suggest such a thing, but those of us who are bright and willing to learn should be given the chance, and trusted enough to prove ourselves. Otherwise without exposure to more advanced tools, those of us that really ‘get’ it are left with a severe handicap in the marketplace….a marketplace severely short on people with SharePoint skills!

  5. The only problem is that you now will have GP’s that will have to use scalpels to do a surgeons job… that doesn’t make sense…the removal of design view was a bad idea. You will force power users to “dabble” in code now instead of using a visual tool.

Leave a Reply

Your email address will not be published.