Donald,

If you can supply me with the name of the person who put you through the incident you described today, I solemnly promise you that if it is the last thing I do, I will hunt down that man and kick him square in his gonads. 

Repeatedly.

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!!

Has it really been over 2 months since I posted about becoming both a better developer and a better developer who was  also 345 lbs of ripped muscle?  It's amazing how the time flies.  I haven't updated you all on my progress as much as I would like, but believe it or not I am *almost* on pace in both respects; expect a flurry of book reviews very soon!  But this post isn't about me and my heroic exploits...no, this is about me and how my heroic exploits have inspired a nation.

My original post tagged several different people, all of whom answered my call to technical arms!  Now that the last person has finally given a response, let's take a look at the original 5 candidates:

James Kovacs

James did not reply publicly on his blog, but I will share the E-mail he sent to me:

from      James Kovacs <kovacs69bitchhaha@hotmail.com>
to         Justice Gray <>
date      May 24, 2007 9:50 PM

'Sup yo? 

I appreciate the challenge, but I've actually decided to forego working on getting better at software development for the time being.  Instead, I am going to focus on my true passion - becoming the best white rapper in North America.  I truly believe there is a niche there to fill, being that Eminem is semi-retired and both Vanilla Ice and Snow haven't really been in the public eye for several years.  I'm also not a cracka-assed poser like those 3 wanna-be OGs.  All I need is one big break and you'll be telling people you received an E-mail from the white reincarnation of Tupac Shakur.  California bitch!  Trust me, the verbal smackdown I lay is going to make LL Cool J and Kool Mo Dee's battle look like a make-out session.   

"Thug Life", as the kids say,
James Kovacs, B.Sc., M.Sc., MCSD, MCT
Microsoft MVP - Solutions Architect
http://www.jameskovacs.com

Upon reading this, I did what any friend of James would have done and laughed hysterically.  Seriously, it takes more than wearing gold chains all the time and waving guns in people's faces for a guy to be a rapper.  Just because James Kovacs can pistol-whip someone at a moment's notice doesn't necessarily mean he knows how to drop the rhymes.  Thankfully, I am humble enough to admit the one time out of 10 million that I am wrong.  This was that time.  Congratulations to James for becoming the whitest rapper at Tech Ed (and perhaps ever) this year.  What a way to make a lasting impression on others!  This was extremely motivating for me; at the least I have contributed to someone fulfilling their long-held dream, and at best I've helped to create the greatest white rap sensation since I last busted lyrics in my Grade 8 year.

D'Arcy Lussier

The first person to publicly accept the challenge, D'Arcy has some aggressive goals involved getting a new web site up and running with webcasts, podcasts, and the like.  2 podcasts a *month*!  5 videos a month!  35 thousand chicken wings a month!  A presentation tour!  Working out every day for 7 hours!  Truly D'Arcy is taking things to the limit.   I can only hope he survives the arduous journey ahead! 

Jason Row

Jason and I have quite the embarassing history but we've put that behind us with his acceptance post!  Mr. Row is a house on fire, raring to blow apart the certification exams at Microsoft, doing some technical reading, and taking his "naughty developer strip show" from the mirror in his bedroom to unsuspecting user groups across his home province.  Forget about all of that though - Jason has become a better developer by receiving a Facebook friend request from none other than Scott Hanselman himself!  Who needs developer credibility when Scott is your friend?  Unfortunately, Jason never utilized his close personal friendship with "Scotty the Body" - as Jason likes to call him for some reason - to his advantage by tagging him directly in this challenge.  Thus he has lost some of the critical coolness points he once had with me. 

George Clingerman

George went beyond the call of duty in several ways:
* he posted a touching explanation of why it took him ten years to respond
* he posted an awesome list of things he is doing
* he then posted another great piece of advice a few days later, thus inspiring most developers to try and buck the trend in our industry and actually have real friends
* he tagged *quite* the list of people, including Rory Blyth and Jason Olson.  I'm pretty sure that Rory is too busy preening at himself in the mirror to accept this challenge* but it's the thought that counts, George!

Donald Belcham

Containing statements like "I've got to find myself", "I've lost my passion", and "I'm poison for you, Donna!", Donald's self-improvement post is cause for celebration; with this much emo in one post, the world doesn't have to mourn the loss of Dawson's Creek any longer.   Equal parts inspirational and melodramatic, I have no doubt Donald was listening to his Best of Backstreet Boys ballads CD while composing his magnum opus.  His thoughts on how to effectively blog are particularly good advice, but all of it is excellent reading if you can get past the image of him lying down drunk and crying himself to sleep after writing this.

I would be remiss if I didn't keep track of the people who had been tagged by someone else in the chain, so here are links to their own posts on developer improvement:

• Scott Reynolds (who wasn't even tagged but did this anyway!  How awesome is that??)
• Kelly Cassidy's original post and followup (tagged by D'Arcy)
• Shane Soldice (tagged by D'Arcy)
• Matt Kiazyk (tagged by Shane Soldice)

Maybe it's just the "new math", but I'm not sure how 5 developers tagged 4 people each leads to only 4 new people.  Thus in an attempt to continue our world-changing goal of self-improvement, I am tagging 5 other people with this challenge and then correspondingly, the challenge to tag 4 others:

Steven Rockarts
David Woods
Jason Haley (as apparently Donald's response to this challenge "hit close to home" for him; time to get it going buddy!)
Bil Simser
Terry Thibodeau

With the sheer number of links in this post, I'm pretty sure I'm going to get dropped off of Google's search index.  Don't let my sacrifice be in vain!

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?

I was very lucky to be able to attend my wife's convocation yesterday at the University of Alberta, and not just because my wife was graduating!  It was also because they had two absolutely amazing speeches, one by the President of the University of Alberta, Dr. Indira Samarasekera (which we'll come back to in a later post) and an incredible, inspiring talk from honorary graduate Sheldon Bowles. 

Sheldon counseled all in attendance to make sure they surrounded themselves with people who are "sunshine" (positive thinkers who inspire you and give you a good feeling) and to steer away from sunshine-suckers (those that are negative and tend to drain you after being around them).  This reminded me of a passage from Rajesh Setty's great book, "Beyond Code" (see my review), that really got me thinking about my relationships and my impact on other people, which I will share with you now in the hopes that it will stimulate you as well.

List A: Write down the names of 10 people in your life who energize you. 

List B: Write down the names of 10 people (if you have 10) who are draining to you.

List C: Write down the names of 20 people who would put *you* on *their* list A.  Do you have 20 people? 

If you don't, what changes can you make in your life to have 20 people on that list?

(This is #1 of #27 in 27 weeks, referenced in my "How to become a better developer" post last week.)

Rajesh Setty (of the "Life Beyond Code" blog) didn't write "Beyond Code" so that he could seduce men and women alike.  Rajesh Setty didn't write "Beyond Code" so that a legion of ridiculously masculine men would develop ridiculous man-crushes!  Rajesh Setty wrote "Beyond Code" because he cared about software developers and wanted to help them reach their fullest potential - the rest just came as a natural outgrowth of his writing.  

I don't know what to tell you about this book.  I would almost say it was like the "How to Win Friends And Influence People" of the software development industry, but it's so much more than that it's almost insulting to use that comparison.    This book is now *tied* with "Code Complete" as a book that I think every software developer *must* read at least once - *particularly* if you are an independent consultant (and I'm a total Steve McConnell fanboy, so you know this is saying something).  Or alternatively, don't read it at all but at least put a copy of it on your coffee table the next time you're bringing a hot date home - GUARANTEED ACTION.

"Beyond Code", as you'd expect, does not have one iota of code in it.  However, what it does have is a wealth of advice on how to stand out - how to stand out to your client, how to stand out among our peers, how to stand out *period*.  While the book is focused towards independents the advice is applicable to *anyone* who is doing software development for a living and wants to transcend just being just another code monkey into something more significant.  The foreword by Tom Peters says "Read it as if your life depended on it.  It DOES!"  This isn't hyperbole.  It's not a long book at all, but it has a great idea pretty much every second page.  I've seriously not had a ROI per page this high in quite a long time of reading.  

This being said, there are some reasons you might not want to read Beyond Code:

1. you don't want to threaten your marriage or relationship by introducing Rajesh Setty and his prose into it  
2. you don't like getting aroused as you're reading software dev books, unless you're reading Code Complete
3. you feel stressed out when you are chased by hordes of the opposite sex wanting to offer themselves to you in the worst way
4. same as point #3, but substitute "clients" or "employers" for "the opposite sex"

Last week, we had a lively discussion on career security on this blog; if you read this book, take its advice to heart and truly implement it's advice, I am almost 100% certain career security is never going to be one of your problems.   Nor will getting some, for that matter!

If you are at all familiar with my scale for rating books (see the bottom of this post for an explanation), then you know that the rating for this book is academic.  No matter how depraved, no matter how undignified, there is *NOTHING* I wouldn't do with this book!  All the way for CERTAIN, even if the only thing I've have the next morning is a goodbye note on the pillow along with some scars and memories to haunt my sleepless nights!  And trust me, sleepless nights are all you're going to get after reading this! 


BUY IT AS SOON AS POSSIBLE.  Then, once you've done that, *read it* as soon as possible!

Some of you noticed that yesterday's post featured the word "security" in quotes at the end.  I don't mean to denigrate full-time employment; however, the #1 argument I hear from people against independent consulting is that is "too insecure".  I always find this strange, considering that I know of a *ton* of independent consultants who have had no trouble remaining gainfully employed for several years as independents.  Did I miss the post where JP Boodhoo or Bil Simser said they were really hurting for work?   Heck, look at the lineup for Calgary Code Camp!  Of the list of speakers, only two out of thirteen are full-time employees.

Further, what is independent consulting actually "insecure" in comparison to: full-time employment?  Many people who talk about full-time being this warm baby oil full-body massage also tend to think you will never ever get laid off or fired from a full-time company.   People get laid off from companies all the time - sometimes for bad reasons (there's been budget cuts), and sometimes for good reasons (Donald stops wearing pants to work).  Being a full-time employee is no guarantee that your job is safe - I knew of a workplace where full-time employees were let go because the contractors on site were outperforming them!   

"Job security" means "keeping your current job".  However, I choose to look at *career* security, which means "always being able to get/keep rewarding employment".  I feel that the second is *far* more secure than the first.

Job security means nothing if your company has to suddenly lay you off after 10 years.  Where is the vaunted "security" then?  Companies do not owe you employment for years of service.  What do you think happens to the full-time employee who coasted on his cushy job, never learning, never growing, and then finds himself back in the marketplace looking for work? 

In contrast, I know a lot of people who have career security.  All of them have several traits in common:

• They are very passionate about what they do
• They are relatively *good* at what they do
• They are constantly trying to better themselves

They are secure for a couple of reasons:

• Their employers are almost always very happy with the work they do
• They are in high demand for the brief times that they "are on the market".

Guess what?  Some of them are full-time employees, others are independent consultants.  It makes no difference.  If you are capable, competent, care about the work you do, and care about continual self-improvement, you are not going to have trouble finding and keeping employment!  That goes for anybody, regardless of their "independent" status or not.    Now, this isn't the *only* way to career security.  The one, true, guaranteed way is to have a fabulous mane of hair and a rugged yet seductive appearance.  Unlike myself though, you can't just coast on your good looks your entire life (I'm sorry to break this to Tom and George, but it's better you found out sooner than later).

If you really want to experience a lack of career security, stop investing in yourself.  Trust me, if you stop learning, growing, and improving, you'll definitely know what it's like to fear for your job, and for your future employment!   You'll feel trapped wherever you are and terrified of the day the axe ever falls; it's a lot easier to get someone to do unpaid OT when they think they have nowhere else they can go.  

Forget about your *job* being secure - is your career secure?  And if you don't think it is, what are you doing to ensure that it is down the road?

Recently, a friend of mine asked me about the benefits of going independent vs. staying at his full-time job.  It seems there have been a lot of posts by people lately about about the benefits of being an independent contractor.  These charlatans make it sound like independent contracting is like having a perpetual orgasm in Orgasmtown.   I'm now here as your trusted voice of honesty to try and correct this horrible misconception; in fact, I am going to tell you some of the reasons why you'd *never* want to leave your full-time job.

You make more money as an independent consultant than as a full-time employee.

At first glance, this looks like a benefit, but it really isn't.  You don't want to be able to save money towards your retirement or afford a nice vacation once in a while; after all, does that build any character?  No, what you want is to be making 50%-200% less per year as a full-time employee.  This goes even further if you have any semblance of talent - everyone loves the feeling that they are being woefully underpaid for the work they are currently doing, because they know this struggle will make them a better person.  

You don't pay as much income tax.

Depriving the government of their hard-earned income tax money is *wrong*.  If the government wasn't able to take 30-40% of your money from income tax *before* you ever even get a hold of it, how would it survive?  Do the right thing and support your provincial/federal governments.  

In addition, you get a ton of tax breaks.  Many "benefits" that companies will offer you are actually tax-deductible, so you get the tax break instead of your company getting it instead.

Oh, sure, being able to write off computers, technical development books, your internet connection, conferences, the gym, etc. as a business expense sounds like a wonderful perk of being indepedent.  But it's *too much* for the average person to keep track of!  Wouldn't you rather be limited by the list of benefits that your full-time company provides?  Your company is what's keeping you employed; not your intrinsic talent or passion for software development.  Obviously there are *no* jobs out there for talented and passionate developers - your company has done you a favor by employing you! So why not pay back the company and give *it* the tax break instead? 

In fact, sometimes your company will go the extra mile and tell you openly that they are paying you less than a contractor *because* of the benefits they're getting a tax break on!  How can you leave that kind of honesty unrewarded?

You and only you decide when you are taking holidays.

Who wants the hassle of getting complete freedom to take vacation pretty much whenever you like, without anyone's approval?  Besides, the company knows better than you when you should take your vacation - they've been approving vacation time for years!! 

You can take a lot more than two-three weeks vacation if you want to - your vacation time is your own choice.

TOO MUCH STRESS.  If you're not working, you're not *living*.  Who wants to take the time out for a trip to Hawaii or even just a month to recharge?  Sure, some people would tell you that they use this time off for personal development and learning new skills but they are liars - everyone who takes more than two weeks vacation time is a slacker.  Do *YOU* want to be a slacker?

You don't work unpaid overtime.

Working 60-80 hours a week and only getting paid for 40 of those hours is a reward in itself. You have *sacrificed* to put your company on the map!  As an independent, companies are contractually required to pay you for OT, so many times they are reluctant to do so.  And if they're reluctant, then how will you get a chance to heroically show them how you're willing to cut your hourly rate in half or more  just so you can accomplish a completely unrealistic schedule?

These are just some of the many problems that come up as an independent consultant; hopefully the list above is sufficient to scare you away from a lifestyle of freedom, flexibility, and financial fortune.  So don't be a masochist like me!!  Snuggle up with the wonderful "security" that full-time employment provides today!!

[addendum: for those of you coming here from Daily Grind #1181, there's also a followup that checked up on the posts from the original people who've responded to the call thus far.]

Be prepared - this blog post is the beginning of a movement that might *change the world*.  By the time you get to the end, you'll see why.

There are two ways to help yourself accomplish a goal:
a) write it down (as we've discussed earlier)
b) share it with someone else

Today I am doing *BOTH*.  In fact, I'm sharing this goal with everyone who stumbles across this post. 
It's one thing to set a goal for yourself, but making it public takes you into a new level of accountability.  Now I am no longer accountable to just myself - now I am accountable to everyone else who regularly reads this blog. 

Among many of his other tips for becoming a better developer, JP Boodhoo advises reading one new development book a month.  I am going one better and making it public: I am telling you all now that I am going to to read (and *comprehend*) a new development book every week for the next 6 months. 

Yes, that's right, by October 21st, 2007 I will have read a total of 27 development books.


Some of you are reading this and thinking I'm crazy, and that this is impossible.  Even more of you no doubt think it's even crazier for me to publically commit to it.  That's fine - but I'm going to prove you wrong.  What sort of a goal is "Well, maybe I'll read a new development book every week for 6 months if I get some spare time?"  BULL.  That's a wishy washy goal that involves no commitment and no real pushing - no real stretching outside of the comfort zone.  "Hopefully I can get this done?"  *Forget it*.  I am *definitely* accomplishing this and that is not wishful thinking - that is a fact.

You can see my reading list below, along with the date I plan to have finished each book.  I still need your help, however; the astute among you will notice that the bottom four entries are the ever-fascinating "???".  This is where *you* have a chance to help guide my destiny.   I need four other books to read and I need the community's advice as to what it should be.  And before you mention it, I know that "Code Complete" is missing from this list; so is Rapid Development, as I have read/re-read both books about 25 million times.

April 23rd: Beyond Code [my review]
April 30th: Head-First Design Patterns (re-read) [my review]
May 7th: Applying UML and Patterns [my review]
May 14th: Working Effectively With Legacy Code [my review]
May 21st: Refactoring [my review]
May 28th: The Pragmatic Programmer [my review]
June 04th: Domain-Driven Design
June 11th: Patterns of Enterprise Application Architecture
June 18th: Enterprise Integration Patterns
June 25th: Applying Domain Driven Design and Patterns, with examples in C#
July 2nd: Refactoring to Patterns
July 9th: CLR Via C#
July 16th: Mastering Regular Expressions
July 23rd: Mac OSX: The Missing Manual
July 30th: .NET Framework Annotated Reference Vol 1
August 6th: .NET Framework Annotated Reference Vol 2
August 13th: Algorithms in Java
August 20th: The Algorithm Design Manual
August 27th: The Little Schemer
September 3rd: Windows Presentation Foundation Unleashed
September 10th: My job went to India: 52 ways to Save Your Job
September 17th: Javascript, the Definitive Guide (5th Edition)
September 23rd: CSS, the Definitive Guide (3rd Edition)
September 30th: ???
October 7th: ???
October 14th: ???
October 21st: ???

So, ladies and gentlemen?  What else do you want me to tackle on my literary odyssey? 

For that matter, what are *you* doing over the next 6 months to improve yourself as a developer? 

With that, let's talk about the world-changing part.   You've seen those "tag" posts where we share 200 facts about us that aren't well known or variants of that.  This time the tagging *starts* with me, but I am going to make this a slightly more productive exercise.  I want everyone who I tag with this post to:

a) write a post about what *they* will have done 6 months now in becoming a better software developer
b) tag 4 other people and get them to do the same.

To start this off, I'm tagging Donald Belcham and the three guys who tagged me previously: D'Arcy Lussier, James Kovacs, and George Clingerman!  Special bonus tag to Jason Row since I know he loves getting tagged on these things.

If you think this is all crazy and aggressive, I've got news for you; I'm just getting started.  Wait until you see the goal I am posting *next week*.  Trust me - you've been warned.

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