Getting Back to Basics

Sometimes we get so good at what we do or we do what we do so often, we wind up flying on auto-pilot. Whether this is evident in your personal life, or work life — its pretty much unavoidable. Given the nature of this blog however, I’m focusing on work life. Being a consultant, I get to poke around at numerous orgs. Most of these orgs have been around for longer than I have and may have perhaps lost their admin, never had an admin, or have just been “brought along for the ride” and when I show up there are many basic things I see that could possibly help the organization in question maintain a better environment for their data, especially when inviting “outsiders” into their org for support.

Here are some items for those entities that don’t have a dedicated salesforce admin to keep in mind when working in their org that go a very long way to producing an environment that is easily support or passed on from one admin to the next, etc.

  1. Fill out description fields, for everything. When adding a new field to a standard or custom object (or even just adding a new object, etc), you are given the option to fill out a description field. Use this. As far as what to say — think about what you would want to know about this field if you had no prior knowledge of your org.  Be explicit, and avoid company specific abbreviations etc. (As an outsider looking in for the first time, you’re likely not going to know all the internal vernacular used within a company, e.g TPS Reports). This has the added advantage of reminding yourself what a certain field is there and what it does should you not need to work with part of your org for sometime. If you’re at all like me, if its been off your plate for more than a week or so — you’ve forgotten it. The description field is a great reminder.
  2. Naming standards for fields: If you can, be explicit in your naming of fields.  A field name ip_Total__c might not be as clear as Internal_Product_Total__c. For a little more typing, you’re building documentation directly into your objects. Yes you can be more explicit in your labels, but speaking purely from a developer point of view, if I’m using Internal_Product_Total__c in my code instead of ip_Total__c, my code just got easier to read as well. (So thanks in advance for that!)
  3. Naming standards for everything: Okay so this may be a cheat just to add another number to this list, but lets forget that for a moment. Why not be as explicit as you can with the naming of things like workflow rules, workflow actions, email templates, email alerts. If it can be read/referenced why not make it clean and obvious what its doing or what its being used for? “Send Email” is nowhere near as clear as “Send Internal Products Total Goal Reached”, etc
  4. Eliminate cruft: This one is a bit tricky as I’m never a fan of deleting…anything, but I’ve poked around enough orgs that I’ve seen many an attempt at writing a validation or workflow rule only to abandon it later for one reason or another. If its in your org and never been used, or something you were just experimenting with — get rid of it. That’s what sandboxes and dev orgs are for. Which is a great segue…
  5. Don’t make changes in production: this is dangerous. Even if it seems harmless you can do bad things. Bad things, in case you were confused, are not good things (unless you learn from them, but again…you can learn from a sandbox or dev org as well). Playing the “what if” game in production is scary for your data…your data doesn’t like “what if” — it likes routine…and tidiness, and maybe long walks on the beach…data is king, honor your king…its good to be king.

To most of you reading this this is hopefully review, however since I only make the effort half the time myself, this is as much for me as it is the newbie who might be wandering out in the big world of Salesforce for the first time. (Do as I say, not as I do right?).

P.S. I promise I am working on some more technical “stuff” but I’m still fighting my way through some of what it is I want to show, but its coming…I swear…I have here somewhere…kinda.



Handling Objections

Often times developers get set in their ways. We like our “norm” and don’t like to change things up all that often. Don’t get me wrong, many of us — perhaps most of us spend time with the “framework of the month” but usually wind up falling back into our platform of choice. I remember when I was fed up with all the various frameworks within the Java world and someone showed me CodeIgniter for PHP. I jumped ship as soon as I could and for the longest time nobody could sell me on anything else. I’d tried rails, and grails, and while those were “fun and new” I was just not as productive or enamored with what they supplied me. From there, someone showed me Django and though it took quite a while for me to gain an appreciation for it, I eventually crossed over. The frameworks were all similar enough in concept to keep me learning at a good pace and eventually it became my framework of choice.

Recently I was a “fly on the wall” during a conversation regarding the introduction of the Salesforce platform to a team of largely Java/Grails developers & while the voice in the room was playing devil’s advocate, he was simply spot on regarding some of the objections that his developers were going to throw at him. As I sat and listened intently (as I’ve been down that road before) I started to think of how I may respond to some of the objections.

  1. I don’t want to be locked into a frameworks way of doing things: lets be honest, there is not a single person on the planet that is part of a Java project that isn’t currently submitting to some framework’s way of doing things. You’re likely using Spring, JSF, Hibernate, etc. You’re doing things the frameworks way already, you’re actual objection is:  “This is new and I’m not used to/don’t want to learn something new.” The beauty here is that if you’re comparing it to Java — the languages are extremely similar and the front end templating is definitely nothing new if your used to jsp tags, JSF, etc. There is no lock-in here that you aren’t already experiencing. When you use a framework you’re accepting its way of doing things. This is no different than what you’re already doing, its just a different “lock.”
  2. Licensing costs — we currently have none: While this is true if you’re not in the .Net world, you likely don’t have licensing costs but you have server upkeep costs. Whether you colocate, outsource entirely, or have your own server room, there is quite a bit of cost built into maintaining your installations, configuring your app servers, locking down the security, applying patches, etc. And lets not forget how much “fun” it is troubleshooting JBoss stacktraces, load balancing your database servers etc. If you’re a server guy, great — you lasted a heck of alot longer than I did, but if you’re DevOps (by force) wouldn’t it be nice to focus less on the Ops and more on the Dev?  While I’ve not run any numbers, I’d bet that once you figure in maintenance of your servers, the licensing isn’t as bad as you’d think. (Lets talk High Availablity, redundancy, failover, disaster recovery another time…*ouch*)
  3. I like to build my front ends from the ground up: So do many people, and many still do. I still haven’t fully submitted myself to Visualforce and often times layout pages with standard HTML. I use JS libraries, stylesheets, the same tools that straight up HTML5 guys are using. The Salesforce platform allows all of this — and guess what? I’ve still managed to learn a thing or two outside of the platform.
  4. We already have a system in place that works for us: That’s great news, but should that force your company into doing things the same way even if given evidence of perhaps a better way of doing things? Shouldn’t you at least want your company to attempt to improve? It may very well be that your way is better, but a company that doesn’t at least explore other avenues in a quest for improvement is doing itself — and its employees — a huge disservice.

In the end we developers are a finicky bunch. We like what we like and many times we can’t really tell you why, or when we do — our arguments seem purely emotional and not always logical. As a developer, I’m trying to keep an open mind about things, and I’d like to think I’m fairly good at that most of the time. After all, I left Django and decided to learn the Salesforce platform. Yea, sure there are things I really miss about Django, but if I went back to Django, I’d miss things from Salesforce. Its about learning, the experience in trying new things. If you’re argument is that you don’t want to be pigeonholed into another framework but then only offer up your “goto solution” — aren’t you already pigeonholed? #FoodForThought



Hello 2015

2014 was a good year. I started flying solo on more projects, became more confident in my own abilities, had an awesome Dreamforce, and began to get a bit more comfortable in my own skin. Largely in part due to me finally saying to myself “screw it, just do what you’re gonna do and don’t worry about what others think of you” — I’d like to say that I’ve held on steadfast to that mantra, but like any new years resolution I had my moments :)

I released two original Salesforce related songs, one of which found quite a following due the the existence of a well established “ThatWhySFDCAdminsDrink” hashtag, the other — not so much. However, I did it. I put myself out there and just said “to hell with it” and I had fun doing so, and plan to do so again (so you may get sick of me).

Since we’re on the subject of what I hope to do this year, maybe this is the perfect time to talk about the traditional “New Year’s Resolutions” — these are probably more “goals” than anything else, but I’m stalling so:


Since I already have my developer cert, and since @KevinSwiggum wants me to get my admin cert, I suppose I should focus on getting that taken care of this year. It really was supposed to happen during my “employment year” so I technically still have until May and I’d like to meet that goal, but when you are part of a small company — priorities shift. I may not make May — but I want to have it done this year.

While we are speaking of certifications, if I indeed make the May timeframe, I’d like to move on to my advanced admin certification. It just seems like something I should do and its something I may not need, but I want. Its the first time ever I’ve actually *wanted* to get a certification.

I want to be more present in the Success Communities. Not just with the music that I hope to continue writing, but in answering questions and being more present and available overall. This will likely prove to be the most difficult for me as hanging out in the Success Communities during work hours is something I don’t want to make a habit of, and being a family man, doing so after hours isn’t ideal either. However, I think I can add value and will continue to figure out a way to do so.

Lastly, I want to find a way to get through the workday with less distraction. Often times I’m coding away and I’ll notice an incoming message or notification of some sort. These notifications are very rarely “important” for work so the less I give them notice during the day, the better. That may mean only checking my email at specific intervals during the day, turning off Twitter desktop notifications, etc. The really important things will fall through to my phone from those people that really need me.


Get back to the gym. I was a three-day-a-week gym rat for a good part of the year, however since I was going over the lunch hour it began to feel as if I was taking too much time away from work. I’m not one of those people that can get up and work out a 5am — my body just doesn’t respond during that time. My mid-day workouts feel better. In April my contract with my current gym is up and I can switch to the gym that practically shares a parking lot with my employer. That will make the lunch hour workouts easier, so its just a matter of getting “something” done between now and then.

Try to write a new song a month. These won’t necessarily all be SFDC related, but I truly enjoy the process. However, I don’t expect this one to stick as I tend to run hot and cold with my creative streaks. I’m also very picky and if it takes me more than 30 minutes to get lyrics down on paper I usually toss the whole thing. Words should just flow and if I’m struggling to make things fit I feel like you can tell in the final result.

Try to play my trumpet on a weekly basis. The trumpet was my primary instrument for 14 years of my life and then apartment life began and I had no place to practice without making neighbors angry. I’ve since lost whatever it was I had back in school. Nowadays, when I hear a Maynard Ferguson tune, or any other trumpet player for that matter — I find I miss it. I’ve got quite a bit of work ahead of me for this but am looking forward to it.

Lastly, blog. I missed a couple weeks at the end of this year due mostly to workload, but hitting a deer with my truck and lack of content that I thought would be actually “something worth saying” were major factors.  I think coming off of Dreamforce with a high level of excitement like I did set me up with some high expectations for myself in this arena. It wasn’t much “work” for the first couple of weeks, but now I’m feeling the true “burden” of coming up with something worth writing. All I can do is try.

In closing, I know some of these things will slip but if I can at least find balance between work, home and my first love music then 2015 should be a good year.

What are some of your hopes for the coming year?




Wednesday Wrap-Up November 2014 Edition

In keeping with my concept of copping out wrapping up the previous month’s events that I found interesting, or mentioned here on the blog, I copped out present to you the latest edition of the Wednesday Wrap-Up. *cough* cop out *cough*

Personal Happenings:

  • I released a Salesforce Christmas song titled “Christmas in the Cloud” — Consumption has been really low though. Hey they can’t all be awesome its not like I’m Taylor Swift or something! (note to self: never release on the day before a holiday during a short work week…#duh)
  • Thanksgiving happened, we hosted — ate too much, then had Thanksgiving Part Deux at another relative’s house where nobody quite understands what it is I do exactly.  “I do computers” thanks @Michaelforce
  • I was given way too much credit for helping Sarah Deutsch write this parody. #Awesomeness — I maybe added three or four lines, but it was a blast to be involved even that much.

Industry Happenings (that I actually cared about):

Okay, confession time: I was very disconnected this month from anything that wasn’t project related. I’ve been living in a self-absorbed worldly mix of jQuery, Visualforce and Apex for several of my clients. Apple could have released the next big thing and I’d have missed it. Throw in the holiday on top of that and for all I know, we’ve invented teleportation, space elevators, and consumer-grade flying cars. To be honest, anything that did catch my eye I forgot to bookmark, except for this: (hint, someone hooked up their car to Salesforce).

So to make it up to all four of my readers — I have some Ello invites hanging around here somewhere, if you want one, let me know.



Christmas in the Cloud

The official start of the holiday season is upon us. I tend to be a bit of a Grinch until closer to Christmas, so I decided to write a holiday song to help me pull out of it early this year. However, the subject took a turn towards Grinchy as the hero of our story gets stuck working on Christmas Eve.

I present for your — (hopefully) — enjoyment: Christmas in the Cloud

5 Tips for Readable Code

I’m a cranky programmer. I’m old and approaching curmudgeon status when it comes to code. I fully expect my colleagues to eventually lock me in a back room somewhere to wait for the mysterious “double flash.” I don’t know how I got here, but I’m here now and I know that I MUCH prefer readable code. Like it or not, there’s a very good chance that someday you’ll have to “open the kimono” and allow other developers to read, and even *gulp* modify code you’ve written. As a consultant, I’ve come into some code that is very easy to read, as well as come into some code that is next to impossible to decipher. Don’t get me wrong, I’m very certain I’ve written some code that has been hard to decipher and probably still do. However, one thing I learned when writing Python code in my previous life was that explicit can be a beautiful thing. Although its entirely focused on Python, a read-through of PEP-8 can do wonders for your code’s readability by getting you to think about a consistent style. I’ve not seen a coding “style guide” from the Apex world (I’ve found this and hope it gains some ground. I haven’t had a chance to consume it all yet, but its a start). That being said, the point of this is not to get into the specifics of a particular language but rather points to ponder in a hopefully “language agnostic” manner.

  1. Method Names: Luckily I’ve not seen the proliferation of bad method names lately that I used to see. However, I like to try to avoid un-necessary abbreviations. Be explicit and tell me what that method does. Such as “UpdateOpportunityStage” rather than “updateStage” — this is a very bad example in that if I’m working in a file like “OpportunityExtension” a method called “UpdateStage” should be obvious, however as an outsider coming into your org, how am I to know if you’re not updating some related object’s custom field stage? For just a few more keystrokes, you can have valuable clarity.
  2. Variable Names: more important, in my mind anyway, are the variable names that you use. Avoid abbreviations here like the plague as well. You’re not saving yourself much in the grand scheme of things, and to an outsider trying to learn the ins and outs of your code (and your business) an abbreviation can be a head-scratcher. For instance, if you have a product called Extra Widgets and you need to work with one in your code, call the variable extraWidget, not “ew” or exWg, etc. There are times when an abbreviation makes sense however, such as when everyone, and I mean everyone, refers to Extra Widgets as “EWs”, then perhaps saying “ew” is fine. However, if I’m in a rather large class file and that variable is instantiated way above the fold somewhere and I run across “ew” — wouldn’t it be a bit clearer if instead of having to figure out what “ew” was, its name told me right away: extraWidget. Again, clarity gets the nod.
  3. Spacing: Python introduced me to something that developers either love or hate. The used of whitespace. In Python, it can get annoying for newbies because indented code signifies your “blocks” — there aren’t curly braces or semi colons. This results in very readable code. It does however mean that many a new Python developer runs into issues at “compile time” because they used a tab in one place and 4 spaces in another. (Don’t get me started on the whole tabs vs. spaces thing…). I love white space and I tend to use insert carriage returns before I introduce larger chunks of logic flow. It separates your code into readable chunks of logic. Like Java, Apex is littered with curly braces and semi-colons galore, punctation that the mind just isn’t used to reading “naturally” — by adding whitespace between the different blocks of logic provides a natural separation and seems easier on the eyes.
  4. Comments: Its been said that good code comments itself, and while this is indeed true it doesn’t get you out of commenting code. I believe the real problem here however is the content of those comments. Of course good code comments itself, but it doesn’t tell you WHY its there or performing its duties in the given manner. It doesn’t tell you what was in the programmers head at the time it was written. Good code comments tell you WHY something was done, not necessarily WHAT it was doing. These types of comments can prove very valuable to any new programmers inheriting your code, or even to yourself when you have to revisit code you wrote months and sometimes even years ago. We’ve all had that moment when reviewing old code where we’ve said: “What the HELL was I thinking, why did I do it like THAT?” only to begin charging down the refactor path until you stumble across that little business rule you forgot about and realize: “Oh, THAT’s why I did it that way!” #BeenThereDoneThat
  5. Coding Shortcuts: I imagine I will catch proverbial hell from some folks on this and its really a matter of opinion (as all of this post is) but hear me out. Code “shortcuts” (like ternary operators) have their place in “oh-look-how-few-lines-of-code-I-took-to-write-this land, but they do NOTHING for readability for me. We’ve all seen them and I’d like to think I’m not the only one that sort of has to blink their eyes and read them twice:
    SomeVar var = (x == true) ? thisVar : thatVar;

    I can appreciate its simplicity and concise presentation, but I still prefer to read this:

    SomeVar var;
    if(x == true) {
        var = thisVar;
    } else {
        var = thatVar;

    While this is quite a few more lines of code its VERY clear to a newbie programmer (or cranky old one) under which conditions the value of “var” will be set to either “thisVar” or “thatVar” Most programmers are used to reading the ternary so it’s not a huge deal, but I know for myself, I always have to re-read those conditions twice to be sure. These are somewhat similar to the whole “one liner if statement” where if you are only checking if a given condition is true, you can do so on one line and eliminate your curly braces etc. (It figures, the one time you can actually NOT use the curly braces, and I don’t prefer it…weird).

In closing — I’m set in my ways and wouldn’t expect anyone to conform to how *I* want things done. However, diva though I may be — I hope that some of these points would cause one to ponder, if only briefly, about the readability of ones code by outside sources. It won’t always be a seasoned vet, or someone who knows your business in and out that winds up reading your code. They’ll have enough to deal with coming up to speed on the ins, outs, and whys of your business, learning the local vernacular, etc. Therefore, making your code a little more legible can remove one less barrier to entry.  And with that, its back in the closet I go.



Take a Break

Over the past 10 business days, I’ve been working heavily on a project for a client that is using Salesforce but my coding efforts have been nearly 100% focused on client side javascript. To be more specific, I’ve been living in the jQuery world for 10 days. Doing so has proven to be beneficial to me as a developer in several ways, and it caused me to reflect a bit on why I feel I really needed this breather:

  1. I’ve been living solely in Apex and Visualforce for two years now & I feel like I’ve lost a bit of ground on some of the things I used to do “pre-Salesforce”. Client side javascript was one of those things. It has been good to rekindle some of that front-end fire and exercise that skill set a bit. The old adage is true, “if you don’t use it, you lose it.”
  2. It revealed some features to me that I didn’t know about the platform. Specifically, the ability for the apex:actionStatus tag to call out to javascript using “onStart” and “onStop” events (perhaps a more technical post on this subject in the future is warranted). In this case, there were several re-renders happening over panels that need jQuery’s attention as well. Since these items may or may not have been part of the DOM on the initial page load, this wasn’t very straightforward. Furthermore the re-render actions were setting defaults from the server that needed to be overwritten by jQuery due to previous user actions, so after the re-render was complete, I needed to re-establish or re-evaluate the user inputs from before the re-render. Due to the project’s usage of the jQuery BlockUI plugin, I was able to tie into that plugin’s “hide” method and then execute the necessary jQuery to manipulate the newly rendered DOM elements. #Slick
  3. Sometimes you just need a break from status quo to refresh your mind. It opens you up to new techniques that living in a silo’d world may sometimes prevent you from picking up. In the end, taking these sideline breaks only strengthens your overall knowledge and that’s a good thing. #AlwaysBeLearning

I’ve still got plenty of jQuery time in front of me on this project so I’m looking forward to further honing that skill set and learning more about what is available to me on the platform side. Breaks are a good thing, but it will be good to get “home” again as well :)




Wednesday Wrap Up — October 2014 Edition

Being fairly new to this “regular blogging” habit that I’m trying to form, I’ve decided that the first Wednesday of every month will be known as “Wrap Up Wednesday” here on  What I plan to do is simply summarize everything that either influenced me, entertained me, or general buzz that interested me from the previous month. Some of it may be related directly to Salesforce but buyer beware — I’m a man of many interests so there may be some other things that sneak in from time to time. So without further delay, welcome to the first of hopefully many “Wednesday Wrap Ups!”

Personal Happenings:

  • Highlight of my year: I got to sing at Dreamforce! (Okay, i really will shut up about this…someday.)
  • I had a lightbulb moment
  • I reflected (perhaps out of place) on what I think makes a Salesforce MVP
  • Sarah Deutsch asked me to rewrite the lyrics to “All About That Bass” and she totally rocked it!
  • I smoked my first cigar and had my first Armagnac thanks to my new buddy Adam Daw. Armagnac — hell yes. Cigar — I’ve got much to learn…maybe @MichaelForce can help.

Dreamforce 2014:

  • The developer group over at Salesforce launched “Trailhead” and I’ve been enjoying watching the tweets come through as people complete the modules/challenges. I’ve not gotten very far myself, but intend to go front to back through all of the content. Some will be review but we can always use review. I’ve already referred a personal friend to it to get him up and going with Salesforce. I can’t wait to watch his progress & its a great way to started on the platform.
  • Lightning Components were opened up to developers and it promises to be slick as hell. I’ve only been able to spend a few hours with it so far, but I believe it will change much of what a developer on the platform does in the future. Our jobs won’t change immediately, there will always be enough apex work to go around, but things will indeed change. Jeff Douglas has a great intro to lightning so check it out.
  • Process Builder seems to be getting quite a bit of attention as well and really will shake things up in admin land. Brian Kwong (aka SalesforceWizard) has several good entries regarding process builder. I’ve not had the chance to do much besides give it a glance at this point but I believe its open beta so it would behoove you to get on this now.
  • Salesforce released Wave and next generation analytics platform. To be honest, I was wowed by the demo at the keynote — but that’s as far as I took it. I can’t focus on everything and I’m scattered as it is :)
  • POODLE just doodled all over SSL. On October 14th google engineers released information regarding a flaw in the SSL 3.0 protocol. Salesforce announced they’ll be shutting down that protocol and mass hysteria ensued. Its all very confusing and hard to even tell if one will be affected by it. There is a link on stackexchange that goes into excruciating detail of what the problem is and further down there is a link that will help you figure out which services may have a problem with this, but for the impatient…I think the magic you are looking for upon test completion is in the configuration section of the results. You’re looking for support of TLS 1.0 at least.

Other tech related stuff:

  • Apple CEO Tim Cook comes out as gay. This shouldn’t matter, but sadly we still live in a world where people think this an issue of some sort.
  • Apple Yosemite was released — and I like it :)
  • The Django project added four new core team members. Congrats folks!
  • An Indiegogo project was launched to help Django provide first class support for third party templating engines. I personally prefer the tempting framework that Django provides out of the box, but this can only help…

There are many more items of tech interest that I am sure I am leaving out but these are the ones I am remembering. This month, perhaps I’ll start bookmarking these things…I just hope I can keep this habit up! For now…



What Makes a Salesforce MVP?

DISCLAIMER: I am perhaps unqualified to speak about such a topic seeing as how I am not an MVP. Therefore, please do not take my words as any sort of official statement as to what “qualities” (for a lack of better term at the moment) one must possess in order to obtain said title.

With that out of the way: Last night I was “twitter lurking” (twurking?!? nah) and ran across a conversation regarding a company that was publicizing the number of Salesforce MVPs on staff for a given RFP. Some lively debate ensued (to which I remained a silent spectator) but it got me thinking, “What traits do I expect to see in an MVP?” I don’t think there is any one group of answers to such a question, but perhaps there are some commonalities. I’m going to try and stick to the items specifically called out in this particular discussion from last night.

  1. Knowledge of the platform: This is a given, but “how much knowledge?” Should this person be an expert in all aspects of the platform? Should they be “consultants?” Given the size of the platform and all one can do with it, I think this is a very, very tall ask. Are there some that can do/know it all? Possibly, but probably not. I mean its a HUGE platform and new stuff is coming out all the time. So in this case — knowledge of the platform sure, but in the absence of some of that knowledge of the details, knowledge of where to go to find the answers, and how to apply them to the task at hand can be more important. It helps to be as well rounded as possible but I don’t expect someone to have all the answers simply because they’re an MVP.
  2. Similar to the afore mentioned “knowledge” lets talk Certification: Should an MVP be certified? I think it certainly can’t hurt at all, and I think most people would expect an MVP to be certified. That being said — I can see situations where they may not be. Maybe they were at one time but their life got busy with children, family, hobbies and didn’t keep up their certification. That being said, the Salesforce community — and perhaps the Microsoft world, (maybe Novell — I’m aging myself here) are the only arena’s in which I’ve ever seen such emphasis on being certified. It absolutely helps your career to be able to say I am a certified X. However, I taught myself how to program in Java in the year 2000. I didn’t understand a damn thing at the time but was able to study for and pass the Sun Certified Java Programmer certification. Had any seasoned Java developer actually gazed upon my code at that time however — they’d have been in shock. I think it was at least a year afterward before I finally fully understood what a constructor was for, or what “this” meant, or what “static” really was. So certification helps no doubt, but how much weight does it actually hold? It at least shows initiative and dedication and I suppose that is something. However, I don’t see that as a requirement when the next three items are considered.
  3. Presence: An MVP should be present. Maybe not necessarily answering all the questions on Stack Exchange or in the Success communities, (I mean who can keep up with @SteveMoForce anyway?) but an active part of the community. Encouraging others, advocating for the platform, and sharing their experiences. The program’s own requirements point out that this can be a Twitter presence,  or Success Communities, blogging, etc. I assume its best to have a mix of all of those environments. First and foremost though — an MVP is present, friendly and approachable. (Queue the segue music…)
  4. Personality: This feels kind of strange for me to mention but I believe personality is probably much more important than many people think. Someone can be the best developer in the world, or the best admin — but if they aren’t friendly and approachable then I think it’d be very hard to fulfill that MVP role. Speaking as an outsider to the MVP world, I feel like those MVPs that I’ve met personally are absolutely friendly and approachable. I think we in the community get somewhat “star struck” if you will and may find it hard to introduce ourselves at first, but when you do you will find that they are very approachable people that are easy to interact with, and are relatable. That’s not to say they’re all extroverted and have all the time in the world to chat with everyone, and maybe some are just quiet, but they’re indeed friendly.
  5. Passion: Above all lies passion. An MVP has a passion for the platform, or the company itself, or a passion for the community. A passion to be knowledgable, to be present and approachable, and to help the others in this amazing community. When you interact with someone it should be pretty obvious from the start whether or not they have a passion for what they are talking about. They exude excitement for whatever it is they are doing. In some cases, they may not be the most knowledgable but they drive forward with energy to learn more and to bring others along with them on the journey. Their energy gets others around them excited too, passion rubs off on  people, its catchy. When people in the community start motivating each other, just look what happens (looking at you @Bill_Greenhaw!)

Is being an MVP more important than being certified? That’s a personal, perhaps company culture issue. Does being an MVP automatically make you a great consultant/employee? I don’t think so, no more than being a great consultant/employee will make you an MVP. I do however think that those traits all work together in harmony. So if there’s anyone in the community that has inspired, encouraged, or assisted you in some way, please take the time to nominate them.

So what do think? What makes an MVP an MVP?



It’s the Community, Stupid!

Last year, I didn’t get it. I attended my very first Dreamforce in San Francisco, CA. I had just recently started a new job working with a former coworker of mine and was thrust into this world of fanatics. I sat there and listened to a very moving keynote, and watched the launch of a new mobile platform for interacting with Salesforce. I attended hands-on training sessions, attended numerous technical talks, and drank free beer. I still didn’t get it. All of this tech was all well and good, but it wasn’t doing anything that “only they could do” so to speak. I didn’t seem to understand the energy that everyone else around me was feeling. I’d been to many a tech conference in the past, and didn’t see people as ecstatic to be there as the 100+ thousand folks that were in attendance last year.

Dreamforce 2014 however is another story. This year I found myself thrust into this new world of people. I had the privilege of hanging out with another developer that for all intents and purposes is identical to me. We have the same insecurities when it comes to our capabilities on the platform and in our professional careers. We both have the same social anxieties, quirks, etc. This person is/was just like me. It seemed that this year we both vowed to come out of our shells and boy did we ever. We talked with strangers, actively sought out conversation (though I believe she was much better at it than I was), we helped each other become part of the community.

During a rather long walk back from the Gala we were discussing past experiences and at one point she just said “I LOVE SALESFORCE” — she practically danced when she said it, and was carrying the biggest smile I’d ever seen on her face. (She’s normally very quiet and reserved). At that point, it hit me: “It’s the community, stupid!”

It’s not the platform, the points, the clicks, the tech — those are all awesome, but its the people. Hearing stories of how this platform, this environment led them to jobs and experiences that have changed their lives is what makes this a great community to be proud of. Watching this normally shy and quiet person practically dance down the street was a much needed blast of fresh air for me, and the timing was perfect.

I’ve been slinging code since the late 90’s. I had passion for it back then. I had passion through most of the last decade but began to burn out in fear of becoming the 65 year-old cranky programmer that the new kids lock in the closet when customers come around. I burned out. Working 10 years mainly answering to marketing firms with very unrealistic expectations of real world I.T. hurdles nearly killed me…I mean that. My career at that time was putting me into very dark places at work but even more so in my personal life and I needed a change. (I know that sounds dramatic but its so very true).

Salesforce was a way for me to sort of change things up and “slow my roll” and its been a great experience. More often than not, I’m working with departments that understand business process, and how development actually works, that things don’t always go according to plan, that what seems like “magic” actually takes time and effort. I can’t say that I’ve found “new passion” for code — I’m always going to be a coder, but I feel my passion is shifting towards helping people. If that help is in the form of creating Apex, Visualforce, Lightning Components, answering questions, replacing a dryer vent, or re-assuring them that they friggin’ ROCK, it doesn’t matter. THEY matter…the people. This awesome place that is the Salesforce community.

I owe a very large part of my Dreamforce experience this year to that community and to people like: Erica Kuhl (@ericakuhl) for putting me out on her stage at the Communities keynote to sing my song, Bill Greenhaw (@Bill_Greenhaw) a Salesforce MVP that thinks that I’m “the stuff” (he didn’t use that word but that could have been the beer…ssshhh), Sarah Deutsch (@sarahforce) who gives the worlds greatest hugs, Michael Farrington (@michaelforce) for asking me “What’s next” and forcing me to think about the future. Brian Kwong (@kwongerrific), Mark Ross (@markross__c), Chris Duarte (@TheChrisDuarte) for pulling me into their circle, it was truly awesome. There are numerous others I could mention (@ericdresh, @andyboettcher) but this is beginning to sound like some weird Oscars speech, so allow me to lump in the other MVPs that I met, you all know who you are.

There are a few more people I’d like to shout out to but I don’t know their names. These were your everyday, non-MVP salesforce users/admins/dev like myself. I was standing in line to grab some books in the devzone when I struck up a conversation with fellow attendees. Before I knew it, they were asking ME questions about the platform and I was more than excited to help with what I knew and point to places for more information for what I didn’t. I was even thanked — maybe it was politeness, but maybe I indeed helped and it felt pretty damned cool. At other conferences, I always felt like I was the one playing catchup and therefore never spoke — to anyone — ever.

Lastly…I owe the overwhelming majority of this “lightbulb experience” to my good friend and developer twin: Jenny Bennett (@jennyjbennett). Without her stepping up her social game, I’d have likely spent another year as a under-confident wallflower. Watching her hit cloud 9 after passing part one of her Advanced Developer exam and seeing her have to fight to hide her overwhelming joy was an incredible and enlightening experience. Hearing her declare her love for the platform in the middle of downtown San Francisco put me over the edge. Even after she left on Thursday — (ditched me more like it) — it was because of her — and nudging from my colleague Kelly Leslie (@kellyleslie44) — that I was inspired and felt bold enough to attend the Cigar Bar party on my own. That is something I’d have never done last year, or any year before that, or at any other conference. I’m pretty sure I won’t have any problems next year getting out there and that’s all because of this year’s Dreamforce experience & the incredible community of people surrounding it. What you all — we all — have going on here is the most astoundingly supportive and friendly community in the industry. It’s not the platform, its the people…I get that now.