• Jeff Mlakar - Thursday, October 18, 2018 9:24 AM

    Jeff Moden - Thursday, October 18, 2018 9:11 AM

    Jeff Mlakar - Thursday, October 18, 2018 8:57 AM

    I like to look at this phenomenon of the negative DBA like this: the nature of the work for a sysadmin (i.e. production DBA) is strikingly different from the development side (i.e. a development DBA). 

    A fun way I like to put it is vampires vs werewolves.  I remember Jeff Atwood gave an analogy like that on his blog Coding Horror. Developers are like vampires and admins are like werewolves. The vampire stays up all night coding and doesn't care much about procedure outside of that. Werewolves are quite until there is a full moon (the DB goes down) then transform to a terrible up-time monster. 

    So it is the nature of the beast that determines this behavior. 

    Anyway - maybe I just like Halloween too much...

    My suggestion is that most DBAs (at least the good ones) aren't anything like that at all.  I can't speak for others but I'm kind, courteous, helpful and a couple of other Boy Scout terms and I frequently and enthusiastically say "Yes" to requests.  I take the time to mentor folks and help their code really cook giving them full credit because my job isn't about collecting attaboys.  So when I say "No" to something, people need to stop and listen.

    And, as I'm sure it is with many DBAs, it's the people that are asking DBAs that are actually negative because they don't remember all the times the DBA said "Yes" or saved their hinnies when something went haywire without actually pointing any fingers at anyone but quietly mentored the people or the group of people whose code or actions caused the issue and how to avoid it in the future.

    And, no... I disagree with the analogy that developers are like vampires, as well.  They're just trying to get their jobs done (although some need to start thinking).  If you want to point the finger at who is actually responsible for the rift between Developers and DBAs, that would be the managers and BA's that think Rome can be built in a single day and write their schedules and requirements that way.  Even though I don't care for what people consider to be "Agile Methodology", it DOES cause people to slow down (contrary to popular belief) and work on one thing at a time despite the whip of the uniformed task masters. 😀

    And, sorry but no... You and your application can't have sysadmin or dbo privs.  It's just not necessary to take on that risk.  Here's how to do it right and how we can continue to pass audits.

    I'm sorry to disappoint on my analogy - it was a generalization. I have noticed it, Jeff Atwood has, and many others. Not sure what you are talking about on the last sentence. Every place I've been in has a separation in job role between prod and dev (or admin / dev) in my example. 
    BTW that reads as quite disagreeable - not the boy scout response I would expect.

    No... it wasn't a disappointment.  It's actually kind of clever but such generalizations do tend to deepen the rift a bit and so expressed my thoughts on it, especially since I'm privileged to work with some great Developers that I do have to say "No" to once in a while.

    My last comment was just an example of one place where I stand my ground whether I have extra hair on my back that day or not. 😀

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)