The New DBA is a Developer This editorial was originally published on Jan 30, 2017. It is being re-run as Steve is on vacation. 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 VisualStudio.com, 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. Steve Jones - SSC Editor Join the debate, and respond to today's editorial on the forums |
