I assume everyone currently living in North America reads Mo Khan's blog.  I also assume that anyone who *doesn't* read Mo Khan's blog is a total loser!    Then again, I also assume that D'Arcy Lussier shooting up with horse steroids twice a day is going to have *no* side-effects whatsoever so you can take my assumptions for what you feel they are worth.

Anyway, if you have been reading Mo Khan's excellent blog (or seen the reference to him on the Caffeinated Coder) you would know that Mo has nominated me for a Microsoft MVP award.  I am flattered by this considering Mo's posts are always among the most intelligent and insightful on the web, which means that to post something like this means he no longer *cares* about having credibility.  That's a sacrifice only true friends make. 

It's unfortunate that Mo makes this recommendation at a time when the Microsoft MVP Program has almost zero credibility itself. 

Yes, that's correct.  You see, there are several fantastic leaders in our industry right now who are *far* more deserving of the MVP on *all* scales and measures of community involvement and technical credibility, and none of them currently have a Microsoft MVP designation.

I'm going to pause for a second while you all pull your jaws back up from the initial shock of my statement.

The people I am thinking of are far too humble to realize that they are being ripped off by the almighty MS.  Fortunately,  as any reader of more than one post on this blog can attest to, excessive humility is certainly not a problem of mine.  I'm going to drag this conspiracy into the light by naming all of these exemplary people and giving you a brief run-down of their background so that you will know as well as I do why the MVP program will never be able to hold itself as a bastion of the best of the best until these people are all MVPs themselves.



Tom travels pretty much all over the place spreading the good news about Test-Driven Development, Refactoring, and various other practices that pretty much everyone with a lick of common sense should know about.  Last year he presented at no less than six separate speaker engagements, will have done another two or three by the time February is over.  He has been running a technical blog that has consistently poured out excellent information for several years.   Why Tom is not an MVP already is quite possibly the second biggest mystery facing the technical community today.


Again we have someone who has tirelessly worked his @$$ off, presenting all over Western Canada and (once again) running a blog with fantastic articles yet with nothing to show for it.  I'm not sure whether it is his previous association with this blog through Hot Developer Corner or his ribald domain name that is keeping Microsoft from giving him the recognition he deserves as one of Western Canada's top technical talents.  David: if you are listening, perhaps changing your domain name to DavidWoodsEnterpriseSuiteForDevelopersExtensiveEdition.com will get Microsoft's marketing division to stand up and take notice.

You let me know how someone can:

• post amazing educational (and more importantly, readable) content for about 2-3 years that manages to educate while not also putting its readers to sleep
• be presenting along the Eastern Coast of the United States
  
• be considered good enough to join the gang at CodeBetter
• have an amazing sense of style

yet *not* be considered for a Microsoft MVP.  I presume there's just residual jealousy over Kyle's chosen location because my brain cracks in half every time I try to piece this together in a logical manner.


I can't figure out for the life of me why someone who tirelessly tours around the entirety of Texas talking and blogging about MVC, NHibernate, TDD, and looking good to anyone who will listen doesn't have some sort of recognition for his efforts.  I am presuming that he is also a victim of jealousy over his "Potential Friend of Justice Gray" certificate.  Microsoft MVP Program people: if giving you a certificate of your own will get you to cast aside the green-eyed monster for Ben Scheirman, I will do so.

Here are some choice quotes from Microsoft's MVP site.  First from the overview:

"When a community participant sees an MVP in a technical community, whether in a newsgroup, as a user group host, a conference speaker, or a respondent in forums, that community participant can be confident that the information shared by the MVP will be of the highest caliber and will help every user make the most of the technology."

Then from the FAQ:

"Individuals are nominated for the MVP Award by their peers or by Microsoft, based on their contributions during the previous year to offline or online technical communities. Each nominee's contributions are then compared to the other candidates' contributions for the same year to determine who will receive the award.

Nominees are chosen from traditional and emerging community venues, including public news groups, forums, third-party Web sites, user groups, book authors, event speakers, Web boards, blogs, and wikis."

Microsoft - I plead with you publicly, let this statement mean something again by putting these men in the spotlight that they truly deserve!!  

Almost a year and a half ago on this very blog, I gave readers two recipes that not only managed to invoke fond memories of childhood book heroes long past but *also* guaranteed you the ability to have any woman you desire hanging off of your 40 inch left bicep.  That was a long time ago and in fact looking back on it it almost feels like a different person wrote it - a well-meaning, incredibly handsome man, but a man full of what we'll call "protein naivete". 

However, today on my supplement shopping trip I have discovered a NEW king of the hill when it comes to *any* protein shake - the BSN lean dessert protein.  Much like the experience of pair programming with yours truly, most protein shake mix is at best nondescript and at worst vomit inducing.   However, I can truly tell you after experiencing BSN's lean dessert protein (cinnamon flavor) that becoming 765 THOUSAND pounds of ripped muscle never tasted so good.    I would probably have the entire canister in one sitting with several litres of milk if I could somehow get around my colon exploding - it is *that* amazing.  The moment my lips touched the sweet nectar of cinnamon roll protein milkshake I could feel the fat instantly melt away from my torso and my shirt rip into shreds as every muscle in my body swelled to 17 times its normal size.  Children cried, men screamed in terror and Mrs. L had to protect me from approximately 2000 lust-frenzied fitness models with nothing but the blade attachment of our blender.

To give you a visual testimonial of this product, here is a photograph of the author prior to discovering BSN Lean Dessert Protein.  See the happy cluelessness as he wanders through his life not knowing which end is up - so scared of his fragile, childlike body that he hides it from view of the camera:


And here, revealed for the first time, is our author after having been freed from the chains of physical inferiority, proud to let his rippling body shine as a light among men and women:

Yes, there are other ways to get yourself in fantastic shape so that you too can walk shirtless around DevTeach Toronto all oiled up and in your posing trunks.  For example, you could try out D'Arcy Lussier's patented Chicken Wing Diet.  Alternatively, you can inject bull semen into your left buttock 3 times a week like the Igloo Coder.  But is either of those methods going to leave you in a state of perpetual orgasmia?  I think not, my friends. 

BSN Lean Dessert Protein comes in no less than *SIX* flavors - banana cream pudding, cinnamon roll, chocolate coconut, whipped vanilla cream, chocolate fudge pudding, and banana nut bread - so you have absolutely no excuse to not be a chiseled rock of a man by the end of NEXT WEEK.  If you happen to pick some up *and* are going to DevTeach Toronto, let me know so we can have a posedown for the AGES!!

Donald recently wrote about how he brings new developers on his team up to speed, talking about wonderful things like pairing and coaching.  Of course, for Donald "pair programming" actually means Donald going up to a developer and saying,  "I'm busy stalking this one chick I met online - code up this feature for me or you're fired".  Say what you will about the Igloo Coder but he is a *master* delegator!   As he likes to paint a pretty picture, he also left out the part about "Tell your new developers they must suck up to you publicly as much as humanly possible or there will be consequences."  Thankfully Shane Courtille stepped up in comments to tell Donald, "Good job boss!!   Everything you do rules!  I made your coffee myself today...I hope you like it" (or something to that effect).  Shane, I can tell you with obsequious enthusiasm like this, your job is definitely safe with Donald.  


In all seriousness, it is good that Donald is involved with new hires to the extent that he is.  I find that a lot of companies forget about how vital it is to treat new people well in their first weeks/months at the organization .  Just as your new hire makes an impression on you in the first week, your company is also making an impression on the new hire.  If you want to ensure your new hire stays with your company or project for a while, it's best to make them feel that they made the right choice.    It's startlingly easy to do this; your company just needs to actually give a rat's ass about its new hires.  You would think this is common sense, but there's actually a wide divergence among organizations and the way they treat their new people.  Some samplings from my own past experiences:

• telling the developer their computer isn't ready for their first day but to just sit and watch somebody answer E-mail for the next three days
• Taking the developer out to the most expensive place in town for lunch and letting them pay for everyone when you forget the company card
• "You know, it's good that you're here because we *really* need someone to come in over the weekend to fold some fliers for our marketing expo next week, and BTW I love the fact that you don't feel anything is 'not my job'"
• And of course, the ever popular "RED ALERT!!  HOLY CRAP PRODUCTION IS DOWN PRODUCTION IS DOWN." 

In my career, I have only felt that possibly one or two companies I've worked for actually got the "new hire introductions" right.  As a team lead in my current gig, I'm the one who shoulders the responsibility of introing new people to our project.  What I do today and am sharing with you below is a composite of those good experiences.

1) Before the developer ever starts, ensure everything they need to get working is ready for them.

I should emphasize how important it is that the following things are ready for your new employee for their first day:

• phone
• computer
• tools setup
• proper software configuration
• logins and access for everything needed to do their job (source control logins, etc.)

Note: I understand that in certain situations you may not have as much control over this as you would like, but try to do what you can to the best of your ability.  Although it's a bit underhanded, if you think IT is lagging have the developer take over your machine and simply tell IT they will be using it until a machine is made ready for them, so your own productivity is being affected.  Note that this won't work all that well if you're not productive in general, but then again if you're not that productive you're likely not being put in the position of introducing new hires.

2) The developer is taken around to be introduced to everyone in the company. 

I want to ensure the developer immediately feels that they are considered an integral part of the team (heck, if we're going to hire someone, they'd *better* be an integral part of the team!), so I will take him/her to meet and greet.  Note that this is not limited to developers - your new hire should be aware of all of the stakeholders in the project, from the lowest to the highest levels where possible. 

3) A document called "Newbie's Guide to the Company" is given to the developer

This can be in wiki or Word format or *any* format for that matter.  This explains the general technical team structure, some company policies, as well as commonly asked questions and answers.  For the first week or two of the employee's time, that employee is responsible for maintaining/adding to the document as they see fit.  If you're doing a document like this, I recommend it being light in both tone and in page count.  The best way to ensure that this document doesn't get updated or read is to make it 70 pages long and looking as if it was written by someone who's never gotten laid.

4) Pair programming

Presuming that we didn't hire this guy or girl on their ability to write scintillating documentation, the remainder of the week is spent doing off-and-on pairing with a developer on the project, as we handle a minor bug/feature.   While we are doing this, we also take the opportunity to give a small tour of the architecture through code and a discussion of how our general methodologies work.  Note that when I say off-and-on pairing, I do not mean show up for 15 minutes a day to see how the developer is doing and then running off to an important meeting.  For the first week, pretty much nothing should be more important then the time spent with the new developer, and this is something that management and the team should both understand. 

5) Lunch

I take the developer out to lunch once or twice depending on the time frame for the week.  Once is with the main team they'll be working with, and once is with me one-on-one.  Always pay for the new hire - if the company doesn't pay for it, cover it yourself.  Some people consider this too expensive, but I counter that the cost of one or two meals is nothing compared to the investment of my time and the team's time if this person leaves after only a couple of months. 

I'm always interested in self-improvement, so I thought I should ask a couple of questions of those that are reading:
a) Are there things you would change about the way I am doing this?  Too much?  Too little?  Not enough tips on stylish shirts and fantastic hair?  Should I get the new devs to go wash my car?
b) What is the worst experience you've had as a new hire?
c) What is the best one?

We've talked about parts of technical leadership in the past, but my wife has gone one further and written a 3-part series of articles on how to be a good software development lead.  Those of you who know me no doubt find it odd that my wife would be dispensing advice on leading software development teams, considering that my wife is:

• not leading a software development team
• not *part* of a software development team
• not a software developer

In fact, the closest that my wife has come to programming would be the day that I attempted to explain binary addition and subtraction by telling her the story of The Kingdom of 1 and the Kingdom of 0.  However, like me, my wife *is* incredibly good-looking, and as we've discussed before, good looks == credibility.  Thus, not knowing programming didn't stop her from writing a fantastic series of articles that I am linking below.   

There are a couple of things I either re-confirmed or learned as a result of reading my wife's articles:

• I talk entirely *too much* about work to my wife
• My wife is an excellent writer
• My wife is horribly, *horribly* biased
• Her articles are *FAR* better guides to leadership than I could ever write.
• Apparently the Igloo Coder has been her second husband for the better part of the last several years
  

Part 1, Part 2, and Part 3 of my wife's guide to being a good leader can be read by clicking on the appropriate part.  She believes that effective leaders:

• do not assume superiority over the team
• do not see their team members as threats to their position, but as measures of their own success in leading
• believe that every person on the team has something valuable to offer to the project
• demonstrate respect and restraint in the way that they speak to others
• give credit where credit is due
• take advantage of every opportunity to put in a good word for their team mates
• work actively as a part of the team
• do as they say at all times

Of course, we all know that being a *good* leader also involves the following attributes, which my wife apparently forgot to list:

• having a wild, lustrous head of hair
• being the best-looking member of your team (or in the case of some of us, your entire organization)
• owning a Macbook Pro
• making posts chock full of bulleted lists

I do try to follow the principles my wife describes, even if they aren't as important as the four I just described.  I am not the fabulous leader my wife believes me to be - I do the best job that I can but I, like anyone else, am always learning.  But her articles are definitely a good starting point for anyone who wants to get into the wild sex and cocaine sniffing that is obviously part of being a technical lead! 

I like to generally avoid having meetings (or long ones, at any rate), but when I do have to schedule them, I like to make the meeting request as impactful as possible.  Since not everyone knows how to write a proper meeting request, I thought I would share an example of an actual meeting request that I sent out, with the names changed to protect the innocent:

Based on Drew's adventures with the ROC application and Team Foundation Server, Kory did a quick investigation and his findings regarding this will SHOCK and ASTOUND!!! But will Kory survive what JACKSON KEVAC has to say about this extraordinary development?  This meeting will change the face of FSS application development FOREVER!!!

There are some key differences between this and the average meeting request, besides the fact you were likely aroused while reading it:

• Judicious use of exclamation points.  This conveys unbridled excitement and gets people interested in your meeting.  I left out the tilde-exclamation combo of "~!" as I think it comes off as a little unprofessional.  Meetings without exclamation points are also meetings without attendees!
• Use of bold font to convey importance.  Nothing gets people jazzed up like seeing their name in bold print.  If you need to convince someone of a point, it is best to reference their name in all caps and bold font before the meeting so that they too can feel like a super-hero.  It worked for this meeting.  It works even better when combined with:
• Use of "action" terms.  Note the use of words like "shock" and "astound" in this meeting request.  Seriously, how many meeting requests do *you* receive with these words in it?  Have you ever received one like that?  Probably not, and that's why *this* one stands out among the pack.  Rather than leaving people thinking, "Another boring meeting to call in sick for", have them anticipate the meeting with fervor.  "I am going to be shocked and astounded!!  THIS MEETING IS GOING TO RULE~~~!"  Any sort of metaphor that compares the meeting to exploding genitalia is *money*.  However, be careful not to overuse it lest you be typecast as the guy or girl who always talks about combustible genitals.
• "Forever".  Why don't people like to go to meetings?  Because they don't think they are of any consequence.  Wouldn't you be more likely to attend a meeting if you knew that the ramifications could be felt for years...even centuries??  Of course you would - you'd be there with bells on!  You need to make sure that everyone knows that the meeting you are scheduling is of earth-shattering importance.   Try to throw in something that makes it a little personal, too!  "This meeting will alter your destiny for ALL TIME!!  I'm talking to you Steve!!!" is a good example.

The important part here is that you are not writing a meeting request, you are writing a comic book solicitation.  It's this sort of BANG~!, WHOO~!, and BANGWHOO~! that people are looking for out of these meetings.  I have not failed yet to have scheduled a meeting with this type of fanfare, where someone did not come up to me afterwards and either:

• compliment me on how exciting the meeting was
• offer themselves to me sexually
• both

Trust me, this might have a chance of happening to you too*!

* that result might be awkward in a situation where you just work with some other dude like Mack and Dickson do, but I figure when you're just two people working together you shouldn't need to have meeting requests anyway

When you think of mentors...

when you think of managers...

when you think of LEADERS...

heck, when you think of *borderline competency*...

...your thoughts likely do *not* immediately gravitate to someone who proclaims himself "North America's Favorite Metrosexual Software Developer".  Thus, I'm sure the fact that yours truly *is* a technical lead comes as a 24-esque shock twist to some of my readers (and might make as much logical sense as Wayne Palmer being President of the United States).  Astonishing as it sounds, there have been several companies where I have found myself leading, mentoring, and (*shudder*) managing teams of developers.  I have no illusions about this having to do with piddling things like "talent" or "credibility" - no, we all know why I'm a lead: because I'm ridiculously good looking eye candy.   However, for the purposes of the rest of this post (and some future posts to come), let's pretend that I *haven't* pulled the wool over everyone's eyes and that there are some secrets to good leadership that involve more than subtly flexing my biceps and batting my eyelashes every time a female co-worker walks by*.

One of these secrets is called *integrity*.  Integrity is the foundation of good leadership, and its absence will undermine a leader faster than any sort of office politics.  Integrity is largely defined as being trustworthy, honorable, and of consistent virtue.  

One way to build up integrity is to practice keeping your word.  Whether these are small things like, "I'll look into getting you off of that massive E-mail list so you can do your job", or potentially huge career-altering things like salary raises, it is imperative on you, the leader, to mean what you say.  You might be able to get away with stringing people along on empty words for a while, but eventually people are going to see through that ruse.  For example, let's pretend that Donald works at my company.  Donald wants to take on more responsibliity - I, however, want Donald to stop bringing the scotch to work before I even consider it.  Rehab, however, is expensive!  I tell Donald that if he can wait a couple of months, he'll be celebrating his one year anniversary and the company will pay for his rehab entirely.  Donald waits patiently and hits the one year mark, at which point I tell him that the company can't pay for his rehab just *yet* - but if he waits for another couple months, *for sure* the company will pay.  if this keeps happening, how long is it before Donald assumes (rightly or wrongly) that I'm just stringing him along?  More importantly, how can I ask anything of Donald from a position of trust?  I've squandered it.  It doesn't matter whether it's truly out of my hands or whether I'm just B.S.ing - Donald is going to assume I'm BSing.

Now, sometimes things happen as a leader that are out of your hands; in these cases, I cannot stress how important it is to be peluccid in all of your dealings.  If there is something preventing you from doing what you originally said, tell the person you committed to why you can't do it, and tell them as soon as possible.  If you tell someone you'll replace their chair and suddenly your funding is cut, it's a lot better to go tell that person right away about the problem rather than simply hiding away and hoping they'll forget.  Trust me, no one forgets about an issue that's important to them! 

Some people think leadership requires a title, while others think it involves pouring cooking oil all over yourself and ripping your shirt off in public.  Maybe they are right, but *great* leadership has nothing to do with titles or public nudity - it has to do with being honest, accountable, and consistent.  After all, if you are able to act with consistent integrity, you've already been successful at a very difficult task - how hard can leading others be in comparison?