Certain Extent

As DBAs, software developers, Homo Sapiens, and lovers we have to solve problems.  There is a common misconception that support is for the more junior folks on a team and thus being good at it is a sign of “being a little baby”.  While support is a great way to learn a software ecosystem and organization and thus “grow” a junior person into a senior one a lot of problem-solving falls to the rock star programmers or wizard DBAs in most organizations.

Yet some of these people aren’t any good at it.  In fact, they are awful.  I’ve seen people that are very good at doing very hard technical things - creating something from nothing, thinking of all the things that could go wrong, refactoring and integrating a large subsystem, etc. - fail at simply fixing a problem with an existing system. You can take your rock star and send them off to fix a support issue and they will return with a confused look, eight hours of wasted effort, and an STD.  Working with some truly gifted problem solvers I’ve witnessed some differences in Attitude, Practices, and Skills that separate the junior and senior problem solvers.  Let’s start with Attitude.

First, there IS a problem

Never deny that there is a problem.  If someone is at your desk, on the phone, flooding your email with red exclamation points, or outside your house knocking on the window there is clearly a problem.  The problem might be that they don’t understand something and the problem might not be your fault, but the issue should be treated with respect as a real problem if they took the time to contact you.  Don’t deny it or argue.  Why would you deny it anyway, because you see support as negative.

Don’t see support as a negative shameful thing or a junior task

As long as things keep changing, there will always be problems.  (This next part is hard to put down in writing) If you aren’t writing bugs you aren’t writing software.  If you aren’t changing systems you aren’t working.  A support issue is not an insult, a bug is not a breakup.  Yes, you should make sure that you don’t write infinite loops, and yes you should make sure that you test the latest SQL Server upgrade before you install it in production at 10 am on the last day of the month.  But in most organizations there is a constant to and fro of creating new things and then fixing issues that crop up with them, so don’t pretend as if a problem is an anomaly.  True root cause and issue prevention are topics for another post, but don’t act surprised that software systems don’t always work as expected.

Confidence

In my home office I have a fortune cookie taped to one of my monitors that says: “You have the ability to analyze and solve any problem”, and over time I have started to believe it (by looking at it 27 times a minute).  The fact is that most people that are good at support are good because they believe that given enough time they could fix any issue.  ANY issue.  Given 20 years and enough coffee they could learn C/C++, reverse engineer SQL Server, learn about cross-platform multi-threading, and fix that bug.

The ability to not freak out and lose it

Something is broken but don’t be scared (its just moving electrons for the highest bidder).  The fact that someone is at your desk and not someone else’s is a good thing, don’t panic and freak out and yell things that you’ll regret later (Aside: yelling is always regretted - only thing I’ve not regretted yelling “OMG ITS MILEY”). Don’t blame people or come off as condescending; assume that they are your desk because they know you can fix it, not because they think you caused it.  Figuring out root cause and a long-term solution are separate things; as are fixing and blaming.  You are in charge of fixing for now, so just focus on that.  Besides, over time a calm person is going to be relied upon more while those who freakout will only end up on reality shows. (They don’t make reality TV shows about guys sitting at keyboards fixing complex technical issues - YET)

Next post - Practices that improve your ability to fix complex technical issues.

peopleware

So a few months ago a bunch of folks at work (lead by cutting-edge Antonio Yon) installed Yammer and now nobody is using it anymore. Why?

First, Yammer is pretty much a private Twitter for use in a corporate environment; its basic features are:

• Basic twitter bits - follow people, short messages, etc.
• Org chart build-out features (you tell Yammer your boss and who works for you and it invites them and builds out your corporate structure)
• Can easily form groups such as QA, Development, The Party for the Overthrow of QA, Party Planning Committee, Party Pooping Committee
• TweetDeck-like UI or web interface, also BlackBerry, etc.
• More features here: Yammer Features

Good things

• You can say things you can’t over Twitter such as “Lunch is here” or “Client XYZ makes me want to cut off my fingers” or even “I wish I was a lumberjack”
• You can ask very very context-heavy questions - if you create a group for your team, it is basically an open IRC channel in which you can ask questions like “in this stored procedure, what does this mean?”

Problems

• Yammer now can export their data to recruiters if/when they go out of business
• Yammer is an immature software implementation of a good idea. The 2nd day that 15 people signed up for it we all got 15×15 emails notifying us that each person was following us - henious shameful bug (Cartesian FAIL).
• The moment a “Vice President of Anything” joins the conversation cleans up and gets more useless or starts getting directed at that person (A VP of anything is more likely to join Yammer than Twitter given its org chart viral features)
• The verb of Yammer is “Yam” which let’s admit it sounds gross

Why it didn’t work here

• People used it to say stupid things “Holy crap look at that bird”
• Given that some people are on Twitter and other social networking sites, the fact that it is yet another client makes people get very frustrated if the context isn’t rich
• It spammed us
• The client crashed occasionally
• I’m not sure, but I think it got somebody pregnant

If Twitter or some other service supported and could be trusted with this functionality I think that having a private one integrated would be a good idea given:

• Twitter isn’t bought by Google (At this point Google knows everything but my safe word: “Knight Rider”)
• It is obvious that you are talking in a private channel
• You could easily install it locally like various other social bits - most companies don’t run a wiki externally, they install Sharepoint or MediaWiki on a spare server
• The “corporate twitter” is either supported by management (and your boss sends out updates and posts stuff there) or is completely outside the corporate realm (just your dev/DBA team uses it as a private IM group).

tools