Tom Kyte has a very entertaining presentation on "Things You Know" which takes a humourous, yet logical poke at what we think we know and the methods we use to come up with those conclusions. It underlines his philosophy of "trust but verify".
As you may recall, I was searching for a DBA to fill an open slot. As with any new addition, it takes time to assess the individual's abilities and figure out how they will be integrated into the team. I constantly find myself wanting to say "That's the way it works, trust me" but try to take time to explain.
For example, the other day we were recovering a database in the development environment. To do this project we had to recreate the controlfile and do an incomplete recovery. While doing the recovery, Oracle asked for an archived redo log that was months old. We got into a discussion of how the controlfile works with an incomplete recovery, how that relates to each datafile and why Oracle may be asking for a real old archived redo log. I think my DBA learned a little more about Oracle and I learned that he now knows the function of the controlfile.
I want to instill into my team members the ability to question why things are setup as they are. Sometimes I just want something done a particular way because it needs to be done fast. However, I also don't want them to take my word because I don't always know...