RE: Definition of Top Class DBA
- From: Iggy Fernandez <iggy_fernandez@xxxxxxxxxxx>
- To: "oracledbaquestions@xxxxxxxxx" <oracledbaquestions@xxxxxxxxx>, ORACLE-L <oracle-l@xxxxxxxxxxxxx>
- Date: Thu, 11 Sep 2014 10:17:04 -0700
I completely agree but the OP wanted an objective way to measure and define
seniority. This Youtube video makes a passable attempt at doing so.
https://www.youtube.com/watch?v=rJq4sEXbaSY#t=483
It's by a SQL Server DBA but obviously applies to other database technologies.
I recommend skipping the first 8 minutes and starting at 08:03. The above link
starts directly at 08:03.
Iggy
Date: Thu, 11 Sep 2014 11:34:07 -0400
Subject: Re: Definition of Top Class DBA
From: oracledbaquestions@xxxxxxxxx
To: oracle-l@xxxxxxxxxxxxx
People often leave out something important... personality, willingness to share
information, being articulate, and learning more than just the DB.
I have worked with some excellent DBAs who I didn't want to even talk to. They
cause drama and send out these emails with massive lists of people on it
whenever they decide for someone reason they don't like anything. Cause drama.
(its not just DBAs that do this). Really good people don't cause unnecessary
drama. Not that many people do this... however, there is a real popular fantasy
writer who put it like this. Patrick Rothfuss gets occasional hate mail from
fans because he is a slow writer. Its not very often. He says its like having a
turd in your rice crispies. You can't exactly eat around the turd.
Willingness to share info: Sending people a link to the doc and saying RTFM is
not real helpful. For people who are not experts reading the docs is tough.
When I need to look at something new I actually look for blog entries first
because someone else dissected the blogs. If people didn't do that, there would
be no point in good DBAs writing these blogs...
More than Just the DB: if its all the DB, then you don't know that much. One
thing I have seen from Oak Table members is they know alot about unix and
operating systems. Quite a few of them have clearly read algorithm books. I
have read a few myself. I know some C (not alot) from school. I find it
helpful. I also try to listen to the developers and sometimes I read their
code. If you just know the DB, then developers will often blow you off, but if
you can speak their language they are more responsive. I see alot of that from
Oak Table members.
Articulate: It takes a lot of practice to explain technical issues to people
who don't know it as well as you or don't know your discipline. If you are very
good you can explain things without using oracle jargon and simplify. It takes
alot of practice to do this... Again, I point to the Oracle blogs. Jonathan
Lewis and others are very good at this.
Other related posts:
