After 10+ years of a dedicated DBA, for the past 17 months, I have purposely chosen to work as a database developer. I decided to do this mainly for two reasons:

1. I want to have a career travel to see whether the grass is greener on the other side.

2. I want to dedicate more time to sharpening my scripting skills in PowerShell, T-SQL and C# and some peripheral items such as XML, CSV and Log processing, which are related to DBA work in one way or another.

Now looking back, I feel the time is well spent. I actually find a lot of fun in developing various solutions for business, and some solutions may easily be transferable for DBA work,

In the first 6 months, I was working in an “Entity Framework Code First” environment, it was interesting initially, but later I felt uncomfortable when data model (from DBA perspective) kept changing somewhat on the fly when each developer team was responsible for a set of tables themselves and each team had the authority to make changes to the underlying tables with high-level agreements among team leaders. But I was the person who needed to migrate the data from old system to the new system thus I relied on underlying tables. With frequent changing of tables (from table name change to column changes to even tables merging and dropping), I kept on changing my code, re-test and then change again and again and again. It is not only me to do all this work, my business analyst had to schedule meetings with me to explain to me the changes and what I should do accordingly etc. It was very chaotic to say the least.

The “code first” principle is so different from my previous experience with data model centered approach, and IMHO, “code first” is probably best fit for small projects with few developers, and little dependency or coupling among product features when using the underlying tables..

In the next 11 months, I was involved in a project that dealt with various files, CSV, Excel, flat text files, XML files etc, and I used PowerShell and SQL CLR functions together with t-sql, bcp utility to process these files, it was fun and challenging. Currently in SQL Server 2016, we can run R script inside a t-sql script, I really hope someday, we can run PowerShell script (or C# script) inside a t-sql script too, this way, we will have one common interface, i.e. T-SQL for all sql server related programming tasks, like stored procedures and functions.

What have I learned as a database developer (after being long time DBA) ?

1. There is a bigger and fun world outside. Lots of SQL Server features can only be appreciated thoroughly when you see they are used to solve tough business issues, such as Service broker, encryption, fancy SSRS reports, columnstore index and various T-SQL windows functions.

2. Under deadline pressure, a developer always puts function/feature as first priority, while treating others, like performance, maintainability etc as secondary consideration. So now when I see some spaghetti codes, like in a select statement, each column is a subquery or select * from (select * from) etc, I somehow do not feel that frustrated as before.

My observation is that majority of developers, whose main program language are not SQL, are writing t-sql codes which are far from the expectations a DBA wants in terms of quality. That may explain why some architects whose skills are in C# / .Net may favour “Entity Framework Coding First” approach to handle business projects.

3. The best DBA is usually ignored by management while the best developer always catches attentions from management because DBAs are proud of “no news is good news” while developers enjoy broadcasting an implemented feature or achieving an critical milestone.

At the end of the day, I was asked which role is more interesting, developer or DBA? My thought is:

DBA is more suitable for people who enjoy keeping on polishing a craft, to make it better and better.

Developer is more suitable for people who like to create new crafts, one after another, non-stop.

So I’d say the grass is equally green on both sides. But with SQL Server vNext goes to Linux/Unix, SQL Server DBAs may find themselves in higher demands in market.

I personally believe it is beneficial for a DBA to plunge into a developer role once every few years. This experience will not only enrich one’s skills but also improve one’s understanding on the other side.