The New DBA is a Developer

, 2017-01-30

I was reading a short piece from Mike Fal recently and it struck a chord with me. I started working with computers as a developer, really a hack programmer as a kid. Friends and I would build small games or hack existing ones to change things. Eventually I was paid to write code, and moved into data work because the pay was better. That was 25 years ago, and I haven't regretted the change since. In fact, I've enjoyed working with data.

Even as I managed data, I always ended up writing some code. Not code, code, like an application that others could use to accomplish a task (though I have often done a touch of that), but rather code to help me as a DBA. I had code to check servers and record values. I had code to move backup files around and generate restore scripts. I had code that would build reports for other DBAs. Some of this code are queries, some are more complex scripts in PoSH (or older VBScript), some could be C# or some other language, but it's all code. Fundamentally, the code isn't much different from the code that application developers write and deploy to clients, web servers, or mobile devices.

There always seemed to be a separation between a DBA that could script something and a DBA limited to simple DML queries. The latter was much less efficient, less productive, less capable of managing a larger environment. As I look to the future, I'd say that that DBA or sysadmin that can't write some code, that is mystified by the concepts of Puppet, Chef, or even unattended SQL installs, is less likely to find good paying, enjoyable, desirable employment. There will be exceptions and less capable people will find work, but given a choice, I think businesses will prefer to get the coding DBA.

Mike brings up great points in his piece, and despite my history as a developer, I've build bad habits over the years. I used to carry around a CD, then a flash drive with helpful DBA scripts on it. I didn't always have a good test process. Part of this was the lack of good modern tools, part was laziness, but just like Mike, I've started to think of anything I do as an effective developer would. I make sure things get done, and I don't try for 100% solutions. I try to get something working, find the problems and fix them, adjusting as I learn and the system changes. I try to build unit tests and ensure that as I change code, I'm not introducing silly bugs because I'm focusing on today's issue while neglecting the requirements I had to meet last week.

Above all, I use version control. That should be a no-brainer for a DBA. We preach backups and restores all the time. Why should our code be any different? These days I've adopted git and I use it extensively. Whether on Github or, I'm ensure I've got my code backed up, and practice restoring regularly on other machines. I create repos as soon as I create a folder to work in, and commit regularly. I don't revert often, but when I do, it's nice to have that backup in my VCS.


5 (1)




5 (1)

Related content


Will the next version of Windows be a "Mini-Me" version of Vista? Who knows, and it's too early to tell, but apparently there's a mini-kernel version of Windows 7, the one after Vista, which fits into 25MB on disk. That's a touch lower than the 4GB that Vista takes up. Granted it's not a full […]


60 reads

An Hour in Time

Daylight Savings time switches a little later this year. In fact it's November 4th this year, after having been in October for all of my life. In case you don't remember which way we move the clocks, here's a saying: Spring forward, fall back.

5 (1)


199 reads

Software is Like Building a House

One of the really classic analogies in software is that it's like building a house. You have a foundation, multiple teams, lots of contractors that specialize in something, etc. And it's an analogy that's debated as to its relevance over and over. I won't go into the correctness of this analogy, but I wanted to comment on it.

2012-10-08 (first published: )

293 reads