• jfogel (7/12/2013)


    Vila Restal (7/12/2013)


    And I maintain my point: A DBA needs to be reliable but behind the scenes. The customer (the audience) shouldn't know they're there because the only time they do is when support is explaining to the customer why they've lost all their data ( because the numpty DBA deleted it all).

    Yes, because it is ALWAYS the DBA who screws up? I don't know what to make of the above and I hope I'm simply not reading it right.

    Indeed you're not reading it write if you think that's what it says (it doesn't say that).

    It means what I said (sheesh):

    DBAs are not customer facing people. the good ones are unsung heroes if you like: when they're good everything ticks a long without a hitch but when they're bad - that's when they become known (that was the point of that example - along with making it clear that plenty of DBAs are numptys and if you're thinking of employing a DBA you want to be sure you don't get one of them). But they are, by definition, behind the scenes and should be much more like sound engineers in attitude and role than the performers such as guitarists and singers. And any DBA with the obvious lack of people skills (irrational hatred of 'coders' and misquoting people and not listening to what people are actually saying) that perhaps some DBAs might have should definitely not be allowed anywhere near a customer.

    I think that this is uncovering two very important tests of any DBA interview process: that they listen to people and comprehend what's being said to them (vital to being a good DBA imho) and that they are team players and respect other people's roles in the process and work to accommodate the requirements of the developers and customers. Companies with DBAs that don't do that have a major problem on their hands.