Mike’s Rule: Know Thy Data

At my former employer, I was hired to do database application support. I spent my first two weeks working with Debbie, our trainer and business analyst. I learned all about our project management system and met the key players.  In retrospect, that was one one of the best things I’ve done in my career. It gave me an appreciation for the business.

Technology people have a tendency to focus on the technology that runs business and ignoring the business. That’s a huge mistake. As I said in a previous post, if you don’t understand the business behind the data, the data is meaningless. In that position, it was especially true. Construction financials are incredibly complex. It’s not just debits and credits. It’s left-side and right-side accounting. I was there four years and the concepts are still a bit blurry to me. Imagine writing a trigger, stored procedure or report against the COR table when you don’t even know what a COR is. (For those unfamiliar with construction, it’s a change order request.)

I’ve seen situations where an IT department will get a request from the business user and just farm out that request to a business partner to develop the situation. The business user knew they needed certain data elements but didn’t know where the data lived in the database. And the business user shouldn’t know, but the IT contact should. This led to countless back-and-forth questions. The time and budget overruns were embarrassing. The next request was mine, and I literally laid out every field, formula, constraint, and specification. The vendor was able to turn that around incredibly quickly with minimal review because they knew exactly what was expected. That was the result of rock-solid specifications by someone who knew the system and how it was being used.

Call me crazy, but I think that as a DBA, we should at least have a slight understanding of the data in our databases.

The Where’s Waldo of Red Flags

Not that I’m actively looking for a new job, but I like to look at my options once in a while.

I came across this posting on Craig’s List, and it’s looks incredibly fishy.

As a DBA, we’re part of a team. I just can’t imagine a DBA/sysadmin being remote 100% of the time. Even if the data center is hosted/remote, this just feels wrong to me.

What red flags do you see? It smells like a bunch of developers got together and built a monster, and now they need a DBA to keep it running.  My red flag is that they have a major app with millions of rows in tables running SQL 2000.

Thanks to Tom LaRock for the title.

Non-DBA skills for DBAs

I’ve read a lot of good blog posts about things people look for in a DBA. A lot of those are skill-related. I think a monkey could do my job if properly trained. Here are a few non-skill related items I’d be looking for if I were hiring a DBA.

• analytical skills
• attention to detail
• aptitude for mathematics
• ability to document processes
• writing skills
• creativity
• problem solving skills
• ability to work with all levels of business users
• ability to translate technical concepts for business users

And if anybody in the Boston area is looking for a DBA with these skills, just let me know.

A Deep Breath

I started writing The Cranky DBA for a lot of reasons. One of them was to boost my professional exposure. One never knows when one will be looking for a new job.

In addition, I’d like to win the all-expense paid trip to PASS this year. The contest closes today. I’m not syndicating this post, so it won’t qualify for the contest.

My queue has been cleared. I will continue to post here, just at a more sane pace. Thanks for all of the feedback. I’ve found that I’ve learned a lot, just by writing about what I know.

Update on Combine