April 6, 2009 at 11:54 am
Nice thought-provoking article. It gives me the opportunity to voice a related opinion...
It seems to me that any good DBA would take pride in also being a developer. The DBA who avoids code and lives his/her life in GUIs is restricting their abilities.
Here's one of my favoirte interview questions:
You have a dev server with 100 small sized databases, and you need to backup them all up and restore them on a new QA server. It is 10am and you don't want to be late for a 11:30 lunch date.
If your approach is to start right-clicking, you will miss your date. If you can query sys.databases and write code to write your code to do the backup, and even the restores with the MOVE option, you can make your date. Better yet, you have already written this and it is in your "tool kit".
I take pride in being a DBA who approaches his job with a developer attitude and skills set.
It seems to me there are lots of opportunities to shine by solving business needs, either behind the scenes or in a more visible avenues.
- Paul
http://paulpaivasql.blogspot.com/
April 6, 2009 at 3:10 pm
Paul Paiva (4/6/2009)
Nice thought-provoking article. It gives me the opportunity to voice a related opinion...It seems to me that any good DBA would take pride in also being a developer. The DBA who avoids code and lives his/her life in GUIs is restricting their abilities.
Here's one of my favoirte interview questions:
You have a dev server with 100 small sized databases, and you need to backup them all up and restore them on a new QA server. It is 10am and you don't want to be late for a 11:30 lunch date.
If your approach is to start right-clicking, you will miss your date. If you can query sys.databases and write code to write your code to do the backup, and even the restores with the MOVE option, you can make your date. Better yet, you have already written this and it is in your "tool kit".
I take pride in being a DBA who approaches his job with a developer attitude and skills set.
It seems to me there are lots of opportunities to shine by solving business needs, either behind the scenes or in a more visible avenues.
by 'developer' do you mean the normal definition of someone who writes application code, or someone with a knowledge of T-SQL and the sytem tables, views and information_schema and how to extract information out of them. To me the two are not the same thing.
---------------------------------------------------------------------
April 8, 2009 at 3:50 pm
There is sooooooo much truth in this article.
In many ways being a DBA is much being a Custodian. As long as the facilites stay in working order, no one realizes what a great job is being done, but if a restroom runs out of toilet paper or paper towels, or a trash can runs over, all hell breaks loose. In many organizations the DBA and the Custodian are taken for granted, although it may be unintentional. I learned to accept that it's just something that comes with the territory.
On those occasions where I inherit a poorly designed database and have to clean it up, I frequently refer to myself as the "Data Janitor" or "Data Janitor in a Drum". 😉
September 15, 2009 at 9:57 am
Interesting article...as someone who has worked in other cutlures somehow i find this US paradigm of more $ = less appreciation somewhat disgusting..all humans need appreciation and some of us DBAs get very tired of the constant fire fighting we have to do to even get noticed. Where I work we have done some things proactively - we got performance dashboard out to application managers to see and they were thrilled, we got a performance baseline done for each server and a binder created that anyone can take a look, and most importantly we have mandated a DBA sit in on database design reviews for new development. With expanding technology that has come to mean reviewing CLr and Entity Framework code too sometimes but better reviewed than push something bad into production and find out later. So in short we have 'created a brand' as Steve said and that helps hugely, although it still sucks that i have to trade in appreciation for what i make. The guilt in corporations around how much they pay people is accentuated by that philosophy, how much am paid is a commitment that is established and shoudl not be traded with the treatment on a daily basis.
September 16, 2009 at 9:16 am
Paul,
I've actually seen quite a few DBAs that shun coding, or development skills. And quite a few people that thought that was a good idea since they could focus on their DBA/SQL skills and not get distracted by being a development hack.
I'm not quite sure where I stand on this, and to some extent I think it depends on the person and situation. Some people are much better admins and SQL people, and having them learn OOP, which is fundamentally different than set based development in T-SQL. It does limit your career choices, but it also makes you a specialist.
I do think that a development DBA, or someone that needs to be involved, especially if there might be CLR code, should be able to at least read and understand development languages. Maybe not be a great writer of code, but a good auditor.
It does help to have a good understanding of how architecture of software impacts design.
If you're talking T-SQL skills, it is critical you be able to write T-SQL (and possibly Powershell in a few years) code. If not, you're not a DBA.
September 16, 2009 at 9:19 am
dma-669038 (9/15/2009)
Interesting article...as someone who has worked in other cutlures somehow i find this US paradigm of more $ = less appreciation somewhat disgusting..all humans need appreciation and some of us DBAs get very tired of the constant fire fighting we have to do to even get noticed. .
I saw this recently, seems to fit:
"Even though they are paid differently, everyone has to feel appreciated." - Roger Staubach
October 7, 2009 at 10:09 am
I agree this article is so truthful! However, as a DBA that left the Corporate IT to help a Business Division within the same company, it is possible to change old habits and learn to promote yourself without becoming a spotlight hog.
I started at ground level on an exciting new project working with engineers and research developers who were very structured within their environment but not held to any of the Corporate Rules. They were in Reasearch after all! They think differently than any other people I've worked with and they make a decision and move on it, never looking back and focusing on the future.
Since my mgmt didn't understand IT lingo or what my job was, I spent many of my 1:1 meetings explaining the importance of Data Integrity and how many hours I spend being proactive vs reactive. Luckily my mgmt was willing to listen and learn.
Self promotion was difficult for me as I was used to hiding in the corner cube, doing what I was told and making sure everything ran smoothly so that my name never came up in any converstation (because it would only be for negative reasons such as performance, server or data issues).
This is not the best for one's career or self-esteem. I encourage every DBA to learn to promote their positive actions. Of course that means making sure you are proactively monitoring and fixing before users are aware there is an issue.
Viewing 7 posts - 16 through 21 (of 21 total)
You must be logged in to reply to this topic. Login to reply