Posted by Josh | Posted in The Rookie DBA | Posted on 10-25-2010
Tags: developers, rookie DBA, SQL Server
Now that I’ve been through a full week in my new development-centered position, I thought I should take a few minutes to note some observations. It was overall a very pleasing first week, with already some lessons and changes made.
Developers (In General) Do Not Make Good Database Stewards
To me one of the most important roles of a DBA is that of data custodian. It’s your job to make sure data is kept safe, both from a security / access perspective, and also from an integrity / availability perspective. So far at least, my experience has shown that developers either a) don’t care or b) don’t know how to accomplish this goal. Now having been a developer myself, I do understand somewhat that their focus has to be on putting out code, not securing and stabilizing their environment. But at the same time, it was downright stunning to see some of the states these machines had gotten into. Even simple backups or integrity checks were mostly missing; granted a lost database wouldn’t mean immediate outages for clients, but it would mean lost work and project time.
People Are Remarkably Welcoming
Even though I’ve gone into this with the attitude that I am not a traffic cop here to lay down the law, I was concerned that any suggestions or attempts at change would be met with resistance. And while that has been the case for a few teams, largely I’ve gotten a very positive reception and folks seem genuinely eager to have me on board. A lot appear relieved that now they will have someone who will be watching over their systems, so they can focus on churning out the code.
The Three D’s Will Be Key
I am going to have a lot of competing demands for my time, so it is going to be crucial that I make good use of what I have. Already projects are piling up and, while people are generally understanding that I am only one mere mortal, they also want theirs done first and fast. I’m going to have to make how I spend my time brutally efficient and wholly transparent. I think that last one is extremely important; if I’m going to be able to say with credibility that I can’t take something on until March, I’d better be able to show clearly what’s on my plate from now until then.
Even though I’m essentially a team of one, I’m going to have to be ruthless about documenting procedure and policy. Because my backups (I technically have two of them) will not be in the midst of my daily work, documentation will be needed to ensure requests are handled appropriately and in a consistent manner when I’m not around. That’s why my rule will be that if I do something more than once, it must be written down somewhere. Period. I hate writing documentation as much as anyone, but it’s a necessary evil.
If I’m going to have success getting these teams to change the way they interact with SQL Server, it’s going to take some serious cajoling, prodding, and yes, occasionally some pointed and sharp yelling. If I come charging into the room acting like some holy warrior who is here to save us all from the perils of bad T-SQL… well, I think the reaction would be as bad as that last image is ridiculous.
This is where my old psychology degree will probably come in handy. You see, I’m going to have to get into these folks heads; not in some Machiavellian, manipulative way (at least not too much), but in a genuine “let me understand your view so I can help you”, shrink-like kind of way. That means I’m going to have to listen to some degree of whining and complaining about how hard life is, how the business rules all and how they don’t have time to worry about defining a proper security model. I should seriously get one of those Freudian style couches for my office!
Ultimately, I had a great week and am still very excited for the future. Yes I’ll be busy, and yes I’m going to have an uphill battle at times. But I really do feel that I can make a difference and help those around me. Maybe I’m naive; only time will tell.