Something that has got me thinking recently is the distinction between an SQL Server Developer and a DBA. I imagine that most people would describe themselves as one or the other exclusively. My CV for example says I’m a developer - that is what I am. I would never market myself as a DBA; aside from the fact I just don’t have the full skillset of a DBA, it would just be an insult to the real DBAs out there whose knowledge and experience in that arena far outweighs mine. Ask me to set up RAID, a backup/disaster recovery strategy or a SAN, and I will give you a blank stare. More than likely, I’d make a speedy exit through the nearest door/window/cat flap.
I’m surrounded!
I signed up for the recent SQL Server Dynamic Management View training offered by Quest Software - a free, one day online conference. This was a very popular event - after all not only was it free, but there were 3 great speakers presenting a range of sessions at levels ranging from beginner to expert. The notes, slides and links can be found here. Midway through, I started wondering how many other “Database Developers” had signed up, as I was surrounded (albeit virtually) by DBAs, and very proficient ones at that. This naturally got me thinking…
Why am I here?
It turns out the answer is pretty simple - to make myself a better Database Developer. Performance and scalability are very important, and are always at the forefront of my mind. As a developer, I want to design and develop a database to support the system I’m working on, that will perform and scale well. For me this involves thinking about the bigger picture. Not just how it performs at the time of development with relatively low volumes of data on development servers but how it would perform with current live data volumes and expected volumes in the future. Thinking about things from a DBA’s perspective, understanding the issues a DBA has to deal with and what skills they use to keep a database server running smoothly is in my opinion, a valuable asset to have. I don’t mean that I should be able to do even half of, what a DBA can do - that would have been a different career path had I wanted to head down that route. But some DBA skills are very beneficial for a developer to have - at least I find they are in my role.
Rise of the “DevBA”?
An SQL Server Developer with a bit of DBA thrown in. Knowing how to diagnose performance issues, make use of DMVs, pinpoint and spot potential bottlenecks has been extremely valuable to me. It’s led to me broadening my horizons, and fine tuning my skills as a developer. For those of you who perhaps work for a small company without a specific DBA role, where pretty much everyone mucks in, I think you’re in the prime DevBA territory.
Another carrot being dangled
The upcoming SQLBits event I recently blogged about is another opportunity I’m looking forward to making the most of. Sessions are currently being submitted in Dev, DBA and BI disciplines. The Dev ones are obviously of main interest to me, but there’s also some DBA sessions that I’d like to attend. I can’t actually recall the point at which I started becoming more aware of DBA-oriented topics, but it’s something that is happening more and more.
Am I a wanna-be DBA? No.
Could I double-up as a DBA? No.
Does being a “DevBA” make me a better developer and increase my technical ability? Yes.