Fixing problems Part 1: Introduction and Attitude Adjustment
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, a missing finger, and an STD. Working with some truly gifted problem solvers I think that there are 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 freakout will only end up on reality shows.
Next post – Practices that improve your ability to fix complex technical issues.