Two things prompted this post. First, I got the latest SQL Server Magazine in the mail this week. I’ve subscribed for like, ever, but lately, I usually just scan it and set it aside. Don’t get me wrong, this mag has done a lot to bring the SQL Server community together, and DevConnections has given me an excuse to lose money in Vegas twice. But, most of what they present is all about mechanics. Rare is the month when the featured article is all about what I’m currently researching. I’m usually hitting up their online archives for information, which believe you me, is well worth the annual subscription rate. The second reason I’m writing this is an article I saw in SQL Server Central this week. It was all about tips for new DBA’s and while well-written and informative, focused on the production side of being a data professional.
I’m a developer. Always have been. I’m in the fairly rare position of having started my career in a development shop, and my first assignment was to build a data model in Oracle 7.3. Needless to say, I was scared half to death, and looking back, I kind of stunk up the room. But, over the past, ahem, 15 years, I’ve realized that most of us start out in administration and move over to development. It figures that I’d be the weird one. Anyway, let me get to the point. I want to talk about my lessons learned from my time as a datachick in a developer’s world. Call it Tips for the New Development Datachick (or Dataguy).
1. Shut up.
No really. I mean it. Shut up. Listen. Your business experts and subject matter experts are your BFFs. Listen to what they’re saying to you. Cultivate your relationship with them. Buy them cupcakes. Make them cookies. Whatever it takes. The database is a reflection of the business you’re in. Who better than the business guy to tell you what you need to know? Besides, when it’s 10:00 on a Friday night, and you’re stuck on something, you want someone to answer the phone when you call. Eventually, you’ll know the business well enough to think ahead and anticipate the coming changes. Database developers are a dime a dozen. Database developers who have good relationships with business analysts? A little more rare.
2. While you’re at it, write it down.
Look, I can’t remember what I wore to work last Thursday. Some days, I can barely remember my name. I write things down. And as my co-workers will tell you, I’m a color-coding freak. Seriously, I have like 20 different colored pens; I’m a little strange at times. Back to the point… There’s a dirty little secret about requirements (and not just functional requirements, sugar… business requirements too). Remember how I said that the database is a reflection of the business? Well, usually sometimes, your business expert friends aren’t going to really know what they want until they actually see data coming out of the database. It’s sort of like buying paint swatches. You can stare at those little color cards all day long, but until you throw something on the wall, you don’t really know if it matches the sofa. My point is, you’re not always going to have complete requirements. Sometimes, your work is helping to define or clarify the requirements. Embrace it. It makes you useful. Write down why you’re doing what you’re doing, and I promise that you’ll look like a rock star when you can go back 6 months later and explain why a design decision was made.
3. Communicate with your other developers.
While you’re baking cookies to win over the hearts and minds of the business experts, throw a few extra into the oven for the other developers you work with. Especially your application guys. Look, I’m a purist. I wish I could design a database that just sat on a shelf and looked oh-so pretty, but I haven’t found that job yet. Why not? Because it doesn’t exist. Your database and your data have to work with applications and tools. I’m sorry. Really, I am. But here’s how I approach the developers I’m working with: Before I ever sit down to design anything, I talk to the other developers involved. I try to understand their challenges and the technical needs. Then, I try to come up with as many viable options as I can for how the database is going to interact with, let’s just say, the application. I make sure that I’m comfortable with any option I present. (There really is more than one way to skin a cat.) Then, I show the developer what I’ve come up with. We talk through the options, and try to come up with something that makes everyone happy. If you just throw a data model over the wall that requires 15 joins to get at the result set the app guy needs, he’s going to quit inviting you to happy hour. And when you’ve got to really put your foot down to protect the integrity of the data, he’s not going to want to work with you.
4. If you’ve got to be the bad guy, be ready to explain why.
So first I tell you to make nice with the other developers, and now I’m telling you to be ready to be the bad guy. Yeah, that’s how it goes. Your prime directive is to protect the data and the database. And, sometimes, you’ve got to make everyone’s life more difficult to protect the data. Do not, under any circumstances, use the phrase, “because I said so”. If you’ve got to make a hard decision, get ready to back yourself up with concrete information. Your fellow developers (if they’re worth their salt) will respect your hard-line stance if you can explain why you won’t let them log in with “sa” and a blank password. After a while, they’ll trust you and take you at your word. But until then, do your homework.
5. Find help wherever you can, be help whenever you can.
Don’t assume that you’re on your own. I’ve found that most other developers are more than willing to lend an ear or a hand. (cookies help) Sometimes you just need to talk through what you’re doing and the answer will become clear to you. I can’t tell you how many times I’ve started describing a problem only to realize halfway through what the right answer was. But I need a willing ear. And, when the answer doesn’t come to me, I need to shut up and be open to new ideas. We all want to be the guy that came up with the cool solution. But at the end of the day, what is important is that the product is as good as it can be. Good developers respect collaboration. On the flip side, be willing to be the sounding board when someone needs to talk through their challenges.