DBA Dreams

  • Comments posted to this topic are about the item DBA Dreams

  • "I've encountered DBAs who seemed ill equipped to administer a home grocery list and checkbook"

    This made me laugh out loud. Thankfully I haven't encountered such DBAs.

    Leonard
    Madison, WI

  • In a job that is, for the most part, worthy-but-dull, rather than the stuff of dreams

    Most good jobs are like that. Glamor is transient, but the enjoyment of doing something well, regardless of the field, is what makes it rewarding.

    There is a huge amount of work required to keep society running. The trick is to find a niche where one is comfortable.

    BTW, I often suspect that can be a poor choice to choose a job that is also your hobby/passion. If you love photography, will you love it so much when most of your time is doing ad photos for Randy's car lot or filling weekend after weekend with schlocky weddings? If you love music, will it be so much fun when you've got to hit the Motel 6 lounge for your 4 nights a week gig, whether you feel up to it or not?

    Even if you get to the more glamorous parts of your field, you still lose the control you had when it was a hobby. The freedom to do what you want, when you want, if you want.

    ...

    -- FORTRAN manual for Xerox Computers --

  • phonetictalk (3/2/2014)


    "I've encountered DBAs who seemed ill equipped to administer a home grocery list and checkbook"

    This made me laugh out loud. Thankfully I haven't encountered such DBAs.

    Yeah that is funny until you come across those DBAs. I have come across more than my share of them as well.

    Jason...AKA CirqueDeSQLeil
    _______________________________________________
    I have given a name to my pain...MCM SQL Server, MVP
    SQL RNNR
    Posting Performance Based Questions - Gail Shaw[/url]
    Learn Extended Events

  • SQLRNNR (3/3/2014)


    phonetictalk (3/2/2014)


    "I've encountered DBAs who seemed ill equipped to administer a home grocery list and checkbook"

    This made me laugh out loud. Thankfully I haven't encountered such DBAs.

    Yeah that is funny until you come across those DBAs. I have come across more than my share of them as well.

    Out of the 20 or so "devleopers" and the 4 "dbas" I've interviewed in the last 2 years or so, only 4 (we got two recently) of the developers knew how to get the current date and time using T-SQL. None of the DBAs knew. Also, none of the DBAs knew the difference between a Clustered Index and a Non-Clustered Index nor how to do native backups.

    According to their resumes, these are people that all claim to have at least 5 years of experience (most of the DBAs were closer to 10 years of experience) and all of the DBA resumes claimed expertise in "tuning queries".

    I thought I'd get over being sick about it but these people have been working in what I believe to be some fairly critical companies. I don't know how they surived for as long as they did and I'm still sick about it because there are more like them out there taking "care" of medical records, payroll, etc, etc.

    --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)

  • Jeff Moden (3/3/2014)


    SQLRNNR (3/3/2014)


    phonetictalk (3/2/2014)


    "I've encountered DBAs who seemed ill equipped to administer a home grocery list and checkbook"

    This made me laugh out loud. Thankfully I haven't encountered such DBAs.

    Yeah that is funny until you come across those DBAs. I have come across more than my share of them as well.

    Out of the 20 or so "devleopers" and the 4 "dbas" I've interviewed in the last 2 years or so, only 4 (we got two recently) of the developers knew how to get the current date and time using T-SQL. None of the DBAs knew. Also, none of the DBAs knew the difference between a Clustered Index and a Non-Clustered Index nor how to do native backups.

    According to their resumes, these are people that all claim to have at least 5 years of experience (most of the DBAs were closer to 10 years of experience) and all of the DBA resumes claimed expertise in "tuning queries".

    I thought I'd get over being sick about it but these people have been working in what I believe to be some fairly critical companies. I don't know how they surived for as long as they did and I'm still sick about it because there are more like them out there taking "care" of medical records, payroll, etc, etc.

    That is quite frightening. Wow.

    Leonard
    Madison, WI

  • phonetictalk (3/2/2014)


    "I've encountered DBAs who seemed ill equipped to administer a home grocery list and checkbook"

    This made me laugh out loud. Thankfully I haven't encountered such DBAs.

    That must be nice. It is clearly an exaggeration of sorts, poetic license if you will, but I agree with SQLRNNR and Jeff, there are plenty of people out there that are lucky SQL Server is such a solid platform these days.. A big crash and they would be out of a job (and hopefully not because their company no longer could exist)

  • jay-h (3/3/2014)


    In a job that is, for the most part, worthy-but-dull, rather than the stuff of dreams

    Most good jobs are like that. Glamor is transient, but the enjoyment of doing something well, regardless of the field, is what makes it rewarding.

    The hardest part for me at times is taking a back seat to developers... All because our work is kind of hidden...

    jay-h (3/3/2014)


    BTW, I often suspect that can be a poor choice to choose a job that is also your hobby/passion. If you love photography, will you love it so much when most of your time is doing ad photos for Randy's car lot or filling weekend after weekend with schlocky weddings? If you love music, will it be so much fun when you've got to hit the Motel 6 lounge for your 4 nights a week gig, whether you feel up to it or not?

    My next (or next next) blog is going to be at least somewhat about this very topic. I think it really depends on the person. I think there are a great deal of folks who are happy to sing for fun and work. You can tell those musicians that last the longest are doing it for fun. Elvis Costello often complains about the business, but just loves making music.

    I know Tom LaRock has his rockstar blogger list (http://thomaslarock.com/rankings/) which I still barely make, but I personally have never wanted to be a rock star, since most of them flame out. I want to be a folk star. People who stay hungry for what they do and love it, are happy doing it during the day, and at night. But it has to come from a love of what you are doing, not just out of a sense that you "ought" to be spending tons of time, or even worse, out of "greed", where you are just pushing yourself to be great because you want to be amazing and make a boatload of money.

    But if you can choose a job that overlaps with what you love to do, going to work will be just as much fun as going on vacation (other than meetings, managers, budgets and all of that... but hey, you do need to make a living)

  • Lous Davidson wrote:

    I've encountered DBAs who seemed ill equipped to administer a home grocery list and checkbook.

    What surprises me is the number of DBAs these days who have very slender SQL skills. Once upon a time, long, long ago (when DB2 ruled the Earth), most DBAs possessed SQL knowledge which put that of nearly every developer in the shade. DBAs knew not just DDL forwards and backwards, but DML as well.

    I'm not sure why that's changed, but changed it has.

  • Jeff Moden (3/3/2014)


    SQLRNNR (3/3/2014)


    phonetictalk (3/2/2014)


    "I've encountered DBAs who seemed ill equipped to administer a home grocery list and checkbook"

    This made me laugh out loud. Thankfully I haven't encountered such DBAs.

    Yeah that is funny until you come across those DBAs. I have come across more than my share of them as well.

    Out of the 20 or so "devleopers" and the 4 "dbas" I've interviewed in the last 2 years or so, only 4 (we got two recently) of the developers knew how to get the current date and time using T-SQL. None of the DBAs knew. Also, none of the DBAs knew the difference between a Clustered Index and a Non-Clustered Index nor how to do native backups.

    ....

    I have interviewed people for DBA positions and have had them not knowing what a null is/ biggest query they have ever written being 25 lines/ not knowing about point in time recovery. So technically poor, but management wanting them because their people skills and we dont need brilliant DBAs because things dont go wrong..

    I always prefer the person who seems genuinely interested in databases with a few holes in their knowledge than someone who has better knowledge and only wants to play with the latest whiz-bang toys

  • Yet Another DBA (5/1/2014)


    I have interviewed people for DBA positions and have had them not knowing what a null is/ biggest query they have ever written being 25 lines/ not knowing about point in time recovery. So technically poor, but management wanting them because their people skills and we don't need brilliant DBAs because things don't go wrong.

    My first couple of questions for a junior DBA are:

    1. What do DDL and DML stand for?

    2. What are the four DML commands?

    2. What type of commands are under the DDL list?

    If they have no clue I may keep the interview going for show, but that pretty much tells me they are probably going to be plodders, and not a true DBA. The plodders are good for running the pre-done scripts that you can't make generic enough for a Level I support desk type to run.



    ----------------
    Jim P.

    A little bit of this and a little byte of that can cause bloatware.

  • Jim P. (5/1/2014)


    Yet Another DBA (5/1/2014)


    I have interviewed people for DBA positions and have had them not knowing what a null is/ biggest query they have ever written being 25 lines/ not knowing about point in time recovery. So technically poor, but management wanting them because their people skills and we don't need brilliant DBAs because things don't go wrong.

    My first couple of questions for a junior DBA are:

    1. What do DDL and DML stand for?

    2. What are the four DML commands?

    2. What type of commands are under the DDL list?

    If they have no clue I may keep the interview going for show, but that pretty much tells me they are probably going to be plodders, and not a true DBA. The plodders are good for running the pre-done scripts that you can't make generic enough for a Level I support desk type to run.

    BWAAA-HAAA!!!! My first question during an interview for Senior Level Developers (front-end or DB) and DBAs is "How do you get the current date and time using only T-SQL"? It's a really good indicator of how good or bad and how long the interview is going to be. Anyone who claims 10 years of experience with SQL Server will usually get the very rude awaking of "I'm sorry but you're not what we're looking for" on that first question if they get it wrong. The ratio across all 3 jobs is now 20:24... 20 out of 24 people, all claiming at least 5 years experience andd some with more than 10 have not answered the question correctly. Only 2 out of the 4 that got it right knew of more than one way.

    I also have a pretest with 3 simple problems that require them to write some T-SQL and I don't let them use a computer to do it. Each problem should take less than 3 minutes and only because I give time for them to write. In fact, I place no time limit on the test. The way they write the code also tells me a lot in many different areas.... especially when it takes them an hour to turn the test in with mostly blank answers. Like I said, these aren't difficult questions. They're easier than a classic "Fizz-Buzz" question.

    --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)

  • GoofyGuy (4/30/2014)


    Lous Davidson wrote:

    I've encountered DBAs who seemed ill equipped to administer a home grocery list and checkbook.

    What surprises me is the number of DBAs these days who have very slender SQL skills. Once upon a time, long, long ago (when DB2 ruled the Earth), most DBAs possessed SQL knowledge which put that of nearly every developer in the shade. DBAs knew not just DDL forwards and backwards, but DML as well.

    I'm not sure why that's changed, but changed it has.

    This growth in the nummber of people hoding a job despite lacking the essential skills and having no intention of learning them isn't a phenomenon restricted to DBA, it has hit many other jobs too. Things have changed in many professions.

    It changed because a large number of people got into the DBA game who weren't interested in what the database was for or what was achieved using it - they saw it as their job to ensure that the DB was backed up properly (but it was almost impossible to convince them that backups should be tested regularly), that plenty of disc space was available, that tape copies of the backups were made and stored off-site, that no-one wrote any SQL other than embedded SQL in Cobol or C++ or whatever, and to set up usernames and passwords and permissions through whatever GUI was available. Not only would they not write DML, they didn't even want to write DDL - databases, tables, and views were created and managed through the GUI, not using SQL. Developers were not be be allowed to create tables (other than temp tables) or stored procedures (so there were no stored procedures because those DBAs couldn't). They would explain their recovery schemes to management, but not to development - so no risk of anyone noticing the recovery plan was unworkable nonsense unless a disaster actually happened.

    How did these people get into thise jobs? By being good at talking and using jargon to sound as if they know what they are talking about. DBA isn't the only job that such people are polluting, I've known middle-managers in software development who couldn't write a basic "hello world" program but were convinced that they could take decisions about programming, others in engineering who thought a baud was the same as one bit per second but also thought they were qualified to define data communications strategy, yet others who thought that bandwidth was the sole determiner of information transfer rate, neither noise nor redundant encoding had any effect (those were so numerous and made such an impression on ignorant technical journalists that "bandwidth" is now regularly misused to meaa "data transmission rate"). Senior manaufacturing managers who think using cheap components is OK because a 10% cost reduction is more important than a 90% reputation disaster think that heir accountancy "skills" trump the engineering skills of teh manufacturing engineer. All these are people who got into positions of power because they could talk nonsense while fooling senior managers into believing they were talking sense.

    But all is not lost. We still have some who call themselves DBAs who are comptent developers, and some who call themselves developers who can do all the DBA jobs if they need to. Of course the DBAs that Jefff interviewed over the last two years prbably hold responsible positions in their current employment, so there are another 5 companies probably heading for disaster; but it's not universal, thank heaven.

    Tom

  • Childhood dreams - mine certainly weren't about being a DBA, or about anything to do with computers. I dreamt of being a linguist, of being a mathematician, a soldier, a space-travel scientist/engineer, a folk-singer, classical clarinetist, a composer. I ended up being an accidental developer, an accidental computer scientist, and an accidental DBA. Languages were useful in my career - used French, German, and Italian for work. I was an amateur soldier very briefly (I was trying to be too many things at one). I wrote a bit of music, some of it got performed (by amateurs, not professionals) but not much. I took two degrees in maths and used a lot of mathematics in my computing work - queuing theory, type theory, formal logic, computability, computational complexity, various bits of algebra and set theory, domain theory, toplogy, and more .... a lot more. I played clarinet in a jazz group and played a lot just for fun but gave it up about 20 years ago; sang in two (amateur) folk groups (lead singer in one of them), in a few amateur opera and musical play productions, and still sing quite often in bars but failed to find time to learn guitar. I actually enjoy computing (inclding DBA-ery) but it certainly wasn't one of my childhood dreams; I was never a professional at any of the things I dreamed of when young, but I've messed around with all of them except space science and enjoyed them too.

    I never found that things were, as Louis suggests they might be, excruciatingly boring, except for a short period early in 1996 when rather than doing a DBA job or a developerjob or indeed anything useful I was acting as an occupant for a desk and chair, with no real work to do, and hoping to be made redundant (because a bunch of empty suits had been promoted to manage the company, and didn't seem to be able to use anyone inclined towards research). Nor did I think that being a DBA was a worthy-but-dull occupation: A couple of times I found myself wishing that it was worthy-but-dull instead of frightfully interesting (what's that Chinese curse about "interesting times"?), but it never was.

    Tom

Viewing 14 posts - 1 through 13 (of 13 total)

You must be logged in to reply to this topic. Login to reply