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

@Wonderlaura, Here’s How I Do Business

Laura Rogers (@wonderlaura on Twitter) responded to a comment I made the other day. Normally, I don’t name commenters, but because I’m sick and tired of being ‘polite’ and seeing clients and the community suffer from it, I’m going to be a bit more straight forward. If you don’t like it, you can kiss my abs.

The comment Laura made exemplifies a huge problem that the community has and that SharePoint has, in its understanding of the capabilities of the platform. She said:

“@furuknap Maybe you just like your customers to be completely dependent on you once you’re done, so you write all custom code for everything” (ref)

Wonderlaura quote

The comment to which she responded was that I said that often, consultants and developers waste months of client time because there is an attitude among some high profile people in the SharePoint community that ‘custom code’, or, probably more accurately, anything built in Visual Studio, is bad, bad, bad, and should be used only as a very last resort, and only after considering kicking small puppies and shutting down the entire company.

I’ll talk in much more detail about this problematic attitude and why those high-profile people, who don’t know how to code (and I think it’s interesting that @wonderlaura considered herself to be a target for that comment), should probably sit down and learn some basic solution development. I’ll do that in a later article, or probably several articles, but not now.

Now, I would like to respond to @wonderlaura’s comment and explain how I approach and work with clients. Making such accusations against me in public is extremely low, especially when coming from an MVP, but frankly, I’ve stopped being surprised at what comes flying from that direction. </rant>

And yes, I resort to third tier development, the dreaded Visual Studio approach, most of the time.

Client Selection

I never name my clients, because that’s none of your business, but also because I can talk about ‘a client’ without revealing anything about who that client is. I always send the client a one-sided NDA that effectively shuts me up about anything related to that client, so anonymity for those is mandatory.

When contacted by a client, I review the client. I don’t care about their problem or their suggested solution at this point, I need to know what the resources of the client are. Questions I ask are:

  • Do they understand SharePoint, or simply use it to screw their clients for money (all will say yes, but many are lying even then)
  • Do they have the resources in terms of (wo)manpower?
  • Are they willing to learn and advance or just perform and invoice?

I have a massive luxury in that I can choose for whom I want to work. I can easily say no to clients who do not take SharePoint seriously, because there are enough companies that do, and that need my assistance.

Client Resources

After accepting a new client, I start by interviewing their current developers or key personnel. This allows me to understand how they can solve the problem they have. No, I’m not referring to how I should solve their problem, I’m talking about what means are within their own reach, using their existing developers, to solve their own problems.

You see, to me, it’s not about what I know, it is about what my clients are capable of doing. I’m not sitting down with an HTML designer and teach them disassembly of the SharePoint assemblies, nor do I expect a programmer to fully understand the intricacies of organizational behavior. I pick the way of solving a client’s problems based on what the client (or their consultants) can do after I leave.

In 9 out of 10 cases, when asked, knowledge increase is on the request list of clients. They want their people to understand more after I’m done than they did before. As such, after fully understanding the current level of their people and the problem they are trying to solve, I sit down and create a plan to reach a ‘solved’ state for their problem, but more importantly, the resources, knowledge, and experience that the client developers need to be able to build their solution further.

Luckily, I’ve written more SharePoint books and journals than anyone in the world, so there’s a huge chance that I’ve already written something that I can give to the developers or to the client to help them understand. You can’t imagine the look on managers’ faces when I can give them a journal issue explaining, in language non-techies understand, what their developers are doing. However, the developers also greatly appreciate getting books and videos that explain the methods so they have something to which they can refer later too.

When breaking down the plan, I divide and assign the tasks so that the developers get a challenge that will take them in the direction they need to go. For a beginning third tier developer, for example, this may be to let them create features that are outside what they have previously done. For a first tier developer, it may be to ask them to build parts of the solution using SharePoint Designer.

Continuous Learning

During the actual work, I also incorporate regular (several times per week) briefings with the developers. These briefings serve both to help them if they are stuck in their assigned tasks, but also to explain, in detail, what I do in the project and the underlying technology of the platform. For a recent client whose developers needed to better understand how web parts worked, I explained to them the ASP.NET engine so that they instinctively knew what happened when SharePoint saw a web part definition. It was one of those “A-Ha!” moments for them, because up until that time, they had thought that web parts where the things they stuck in the web part gallery.

I don’t expect all of that to sit after just a few hours, so many times, I also record these sessions so the client can review the ‘lectures’ afterwards. This often goes into the client’s learning libraries, to be used with new employees too.

Finally, in every project, I also set aside a minimum of 20% of the time to do thorough walkthroughs of the entire solution with all the developers and lastly, to write proper documentation, both inline code and deployment and other documentation.

So, all my clients get:

  • Training and resources tailored to their current level and desired goal
  • Detailed mentoring while they are themselves solving their problems
  • Full walkthrough and detailed documentation of the solution

The result of this is that when I walk out the door, the client and their developers and key people know both how to solve their problems and how those problems arose. They end up having built their own solutions so they know that inside out. They have attained the skills required to support and maintain their solution in the long term and also to solve similar problems.

Does it Work?

I would like to say that so far, no client has come back to me to solve a similar problem to one I’ve already helped them solve. Many have come back with new types of problems, probably because they see that what I do isn’t to solve their problems, I make them capable of solving their own problems.

So, Wonderlaura, my clients depend nothing on me after I’m done. In fact, if they call me to ask about anything related to that solution, or even similar solutions, after I am done, I see that as a failure on my part, and obviously help them free of charge. I think that has happened once or twice, and I’ve always thoroughly examined my methods afterwards to figure out what I can do to improve.

But, I also end up writing ‘custom code’ in 95% of the cases. Recently, I solved a client’s Publishing framework problem, a problem they (and Microsoft support) had struggled with solving for two months. I solved the problem using ‘custom code’, including all the training, planning, documentation, and knowledge transmission, within a week. Incidentally, these developers did not know how to do any .NET development.

In a previous client case (about two years ago) I ended up creating (and teaching) a new framework for deploying and maintaining sites and site collections, including custom WSP solutions, within three days. This framework eventually made it into USP Journal issue 1/8, and the client for which I worked ended up completely restructuring their entire project so far (a six-month project) in another week, after I had taught them how the framework worked.

So, yes, I would say it works.

I have no idea how @wonderlaura approaches her clients, and how much time she spends teaching her clients everything she does, leaving documentation, videos, and detailed explanations, and empowering the client to help themselves rather than just solving the problem for the client, but this is how I do it.

I leave no client dependent, and I will not have some random MVP run around claiming otherwise.


Pin It

I’m Back! Prepare to Cringe!

Did you miss me? All you retards with nothing better to do than comment on my attitude? Informing the world how much better it is to kiss ass than to make a stand? Prostitutes with so low intelligence that you don’t even realize you’re selling your integrity and your life for money, and it isn’t even your money afterwards.

Sometime life needs a bit of a reboot. Stepping back to see where one is and where one is headed. Sometimes, that can be pleasant, sometimes it’s a pain.

I’ve come to realize where all the shitty proverbs originate and their purpose. They were just lining up to apply to me. What they didn’t expect, though, was that I would take it standing up, not whimpering like a hurt little piglet. Bullets bounce off me, as do sticks and stones. How do you think words strike then?

Regardless, the outcome in my case is that I needed to take a break and reorganize my life. As said and done, my life reorganized, bad habits dropped, bastards pruned, and so on, and I’m here again.

No I’m not retiring or anything like that. You won’t get rid of me that easy. You won’t get away that easy.

I’m Reloaded!

Does this mean I’ve changed my attitude? Hell no, it’s even better (or worse) than before, because now that I’ve had time to observe both myself and the world around me with refreshed eyes, I’ve started seeing more that is messed up and that needs a serious reality check.

I see problems on the horizon. Heck, horizons be damned, I see problems up to my knees whenever I step into the world of SharePoint.

It’s time to get out the vinegar.

Pick up a box of tissues on your way home from work.

If you have a pot, it will be stirred.

If you have an ego, it will be bruised.

If you have an attitude… Oh, boy, we’ll have a dance to remember.

Are you ready? You should hope you are, but I can tell you this much, to continue the movie quotes: Here comes the pain!


Pin It