Saturday, October 30, 2010

Help Wanted!

   In the "Spiderman" movie, his mom said to him, "You're not Superman, you know!"

   Are you?

   Probably not.  At most, one of my readers is.  More likely, none.

   Chances are pretty good that, once in a while, you run into something you're just not able to complete alone.  So what do you do then?

   Some people would say, tough it out.  Give it all you've got, and if you are indeed excellent, you'll get it done.



   Yeah... right!  And the sun will shine once those monkeys I mentioned before, stop blocking it.

   Quit banging your head against the wall.  Ask for help.  Admit that you're human.  (Uh, you are, aren't you?)  Done correctly, this will get the problem solved the fastest, and with the least amount of total pain and effort, including not only yours but others' too.  That's what being excellent is all about, not about looking like Superman.

   But how should you ask for help?  Not just how to phrase it politely, like yo' mama should have taught you, but how to lay the groundwork, so that you will likely get a good, helpful response.

   Eric S. Raymond wrote a wonderful essay titled "How To Ask Questions The Smart Way".  He's best known in the computer world, and the essay is mainly aimed at getting technical help from "hackers" (rant on the media mangling of that word, omitted).  And yes, his attitude is often condescending and abrasive.  But...  the principles he outlines are pretty much universal.  In fact, if you apply them outside that realm, you'll meet with even greater success.  To break it down, way down:

  • Try to solve it yourself first.  The essay details several information sources to try, at least for technical problems.

  • Ask the right person or group.

  • Communicate well, including:
    • Use correct grammar, spelling, punctuation, etc.; don't m4Ke 7h33 07h4R P3r51n 5p3Nd 4 !07 uv h1z 7yM3 f!9uR1nG oU7 wU7 u m33N!
    • Get to the point. Preferably as early as the Subject line, if asking by email.
    • Be specific about the problem or question, and what kind of help you're looking for.
    • Give all the data you have.
    • But still be concise.

  • Say what you already tried, and why that didn't satisfy you.

  • Above all, be nice about it!  Don't assume that any problem you're having, is his fault, or even not yours.  Don't expect an instant solution on a silver platter.  You're probably not paying the person who's helping, so be grateful that they're putting forth any effort at all for you.

So now, dear readers, as usual, it's your turn.  When do you ask for help, and what do you do to help ensure that you get it?

Sunday, October 3, 2010

Don't Burn Out

   Remember the boss from last month's entry, who wanted you to rush rush rush and hop to it on his supposedly need-it-now task, which rarely really is?  That kind of boss is likely to also pile unreasonable amounts of work on you, especially claiming again that it's an "emergency".

   Don't fall for it, unless of course it's a true emergency.  That means, something not only unforeseen, but unforeseeable.  It's a manager's job to plan for the things likely to go wrong, allow slack time for them, and recovery time afterward.

   If you give in, even once, you set a precedent.  The boss now knows he can count on you to work your buns off, probably for little to no recognition (let alone actual reward), on a whim.  He will expect you to do it.  If you don't do it next time, you are "not meeting expectations".  Never mind that the expectations are utterly unreasonable.

   There is an old military expression about this: "Take more than your share of objectives, and you will be given more than your share of objectives to take."

   It can be tempting, as so many short-sighted companies pay all glory and homage to the fire-fighters, but slight the diligent workers practicing fire-prevention.  In the programming world, this shows up as support for, for instance, 80-hour weeks of debugging, versus 40-hour weeks that include good unit test coverage.

   Repeat after me: "Your lack of planning does not constitute my emergency."

   Okay, putting it that bluntly may not play well with the boss, but if you get fired for sticking up for yourself, well, would you want to work for such a jerk anyway?  (By the way, one of the first jobs I ever quit, I quit partly because the boss was a jerk.)

   One last note, lest some of you make some unwarranted connections: no, I have not personally worked for a boss who was all that prone to pulling this particular stunt.  It is not why I am leaving Comcast, nor is my boss anywhere near that bad.  But it is one of the canonical "Stupid Pointy-Haired-Boss Tricks" (with no apologies to either David Letterman or Scott Adams).

Dogfooding: Rosetta Stone

   Remember a couple months ago, when I wrote that Quitters Can Win?  In the software development arena, we have a tradition called "dogfooding".  It didn't originate with us, but we do try to do it when possible.

   What's the connection, you wonder?  "Dogfooding" is short for "eating your own dog food" - click it for the Wikipedia explanation.  Go on, I'll wait.

   I've "dogfooded" that blog post, by quitting.  Long story short, I've submitted my resignation at Comcast.  On October 18, I will be starting a new position with Rosetta Stone, in Rosslyn VA.

   Meanwhile, you may be wondering, what took so long since my last post?  Jobhunting is busy work, but that's no excuse, especially as I got the offer weeks ago.  Consider it... dogfooding my prior post, "Can It Wait?" ;-)