A DBA’s Developer Experience and After-Thoughts

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.

Advertisements
This entry was posted in Uncategorized. Bookmark the permalink.

6 Responses to A DBA’s Developer Experience and After-Thoughts

  1. Jonathan Bernard Rapisarda says:

    Hi There,

    Your journey is a very valuable one to share! I am a Sr Developer these days but I have been a DBA and Business Analyst in previous lives. I agree wholeheartedly with your statements and in my own experience have been seen as a unicorn developer because I know how to properly create code. Recently, I had a manger not believe my work output because he said that I had added all the required calculations and that he would expect it to run for two minutes at least and I told him that 16 seconds wasn’t really acceptable to me but it was as good as I could make it. There is an art to crafting true queries and this one involved using a nested subselect as key value pair and then joining back to the same data set but using the underlying index to support a much faster return time. I used a variety of databases and sometimes CTE and sometimes nested subselect but we both know the reason why you would use both in same query ;-).

    I, too, enjoy using the embedded R capabilities. Have you tried using xp_cmdshell in a recurisive function to be able to get Powershell to activate on a rowset? Once I did this, with a custom assembly, to download the content of a heirarchial website and store the results of the shredded XML into columns. It wasn’t too slow and this was before CTE was available in SQL Server. Full-text indexing could then be applied to make resulting queries come back in good times.

    Great article, here is too the rise of the DBA/Developer!

  2. Vin Pun says:

    Very true. Every DBA should work as a Developer, so that they would know that they can’t always blame developers for bad query (coz for developers purpose serverd is importatnt) 😉

  3. Jennifer Mahoney says:

    Thanks for a great reflection! I also agree that making the time to “try on” different hats as relates to the data you (as a dba) are tasked with maintaining has significant value. I come from a logistics/operations background, and moved to reporting and ETL work 9 years ago. I’ve found that dba’s set the operational foundation for everyone else to gather and interact with the plethora of data out there. Those worth their salt understand the myriad demands made by various flavors of developers as well as transactional users. They help put appropriate structure in to keep things humming, while making space for ‘wild west’ development, but in a way that allows eventual honed product to be “operationalized”. This ensures data is accurate, maintainable, and flexible as the needs of the business change.

    No matter what my role as relates to data in the future, I will always look for a solid dba to work with… they make all other data related jobs much easier.

  4. almondelm says:

    Thanks for sharing great article and your personal experience. Changing hats does resolves functional silos.

  5. c says:

    This is a very informative experience. Glad to hear things in different perceptive.

  6. Thanks for sharing your personal experience and after-Thoughts.
    I would like to be a bit personal too and introduce myself:
    My name is Bracha Goldstein .I’m a computer programmer working mainly on SQL Server and .NET
    I’m 56 years old. Recently I quitted my job recognizing that life is too short and if I won’t hurry it will end before I leave my foot prints in this fantastic world.
    What foot print do you ask?
    I developed a software named JOINI. It is a simple ETL tool for dbo and developers.
    I would like people to know JOINI exists, believing it can help them in their daily tasks.
    Beginners which find SSIS to be a bit complicate to use, can use JOINI, which looks and feels like File Explorer.
    As you mentioned in your first 6 month experience as a developer, you faced the difficulty of frequent changes of the data model.
    I find JOINI extremely useful handling those frequent changes.
    If you are interested, I can link you to a YouTube demonstration of JOINI.
    Thanks,
    Bracha Goldstein

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s