Saturday, September 02, 2006

The more you understand...

The less you have to memorize.  Been a while since I linked back to Kathy Sierra, but her posting on "How to get users to RTFM" had a graphic I really liked (take a second to click the link, it is right on top).

Many people presume I have "memorized all there is to memorize" about Oracle (or "much that there is to memorize").  Not true - I hit the manuals every day, every single day.  To look up esoteric syntax, to get a clarification, to refine my understanding of how something works.  It is less rote memorization than it is understanding of the fundamentals.  I can look at a proposed trigger and in a couple of minutes explain why it won't work in real life (you'd be surprised how many don't - triggers used to enforce integrity constraints most times have multi-user logic flaws).  It is not because I've memorized 100 use cases - rather that I understand the concepts in the database (multi-versioning, non-blocking reads and what they mean to us and why we care).

Anyway, read her post (it is a long one) - I think she makes a good point.  I liked the classification of the types of reading material necessary for a product - I think I do mostly #3 and #4 - #3 in the books and #4 on asktom.



Anonymous Anonymous said....

Learning something new is about developing a 'frame of reference'. When you know nothing about a subject and want to learn the basics you are actually learning alot of little things in order to do one thing. Eventually you get to a point where you understand the concepts and learning one more thing is just one more thing.

One mistake I see alot of people make on the Oracle forums is pointing people who are newbies to an 800 page document and go read this. Now since they don't work with you and you don't know them you don't owe them anything else. However, I see this at work too.

The best way to help a new person learn something is focused learning. Read this part of the manual. Learn about this one thing. Then tell them to query the data dictionary and learn a little more about it. Then if you have time, they can go talk to you about it.

I think a system of multiple series of inputs is the most productive way to learn and it should be iterative.

Lets say a newbie wants to learn about constraints.

1. point them to a section in the concepts document or whatever where there is information about constraints.
2. show them where the DDL is in the sql reference.
3. Let them play with it. Tell them which data dictionary views to query to learn more(and where the data dictionary docs are).
4. encourage them to google more information and ask questions on forums.

By then they will learn more and have discovered more things they are interested in. Then you can move to something else.

Focused learning is best. It really is up to the new person to lead this, but I see alot of people pretty much kill people's interest by going RTFM and pointing to an 800 page document or just biting their head off. Totally unproductive.

It is now in vogue to tell newbies to read the concepts document. That is way too much information for most new people. Its far better to help them find a spot in the docs to read.

I have also seen people recommending Jonathan Lewis's new book to complete newbies. That is absolutely NOT a newbie book. It has WAY too much information for a new person. Its far more productive to start with something alot less detailed or they will be overwhelemed, then move on to Jonathan's book. That book probably is not useful to people who have not been around for a little while or have considered other knowledge/experience with other software technologies(especially databases).

Sun Sep 03, 02:54:00 PM EDT  

Anonymous Anonymous said....

btw tom. Here are two very good software blog sites. I am not associated with them. Just passing it along...
If you go to hotsos support, they are actually using their bug tracking software.

Sun Sep 03, 02:59:00 PM EDT  

Blogger Alberto Dell'Era said....

Would you be surprised if I told you that the possibility of building a mental model is the #1 reason while I chose Oracle as a "career" ?

For, even if it's a commercial and so "closed" product, a lot of info exists about its inner workings (partly by Oracle's design and partly because there are so many bright people that hack it ;) and so anyone can get on the right (pun intended) side of Kathy Sierra's graph.

Sun Sep 03, 05:59:00 PM EDT  

Blogger Atul Kumar said....

I am big fan of yours specially I liked idea of , I would like to see something on Oracle Applications on your blog (If you have time )


Sun Sep 03, 07:00:00 PM EDT  

Anonymous Stephan Freund said....

Memorization is underrated. For example, at the most basic level, you have to know how to call things before you can even talk about them or have a chance of understanding how they fit together. That's why new students of medicine spend so much time learning the names of bones, organs, muscles etc. In Oracle you need to know things like what the SQL area is and the dictionary cache and the AWR before you can move on to the bigger stuff like tuning. Memorization is not the goal, but it is the first step and understanding follows so much faster.

Tue Sep 05, 03:52:00 AM EDT  

Blogger Mathew Butler said....

But knowlege makes everything simpler according to
the laws of simplicity

Tue Sep 05, 09:39:00 AM EDT  

Anonymous RobH said....

"Not true - I hit the manuals every day, every single day."

You've said this before and I really took it to heart. I find now I look up the sytanx, check for more info, possible links to other info.

I've found that the more you use the docs, the easier it is to find what you want and the better you get at understanding them.

I have the firefox plugin to search oracles doc enabled and now I use it more than the Asktom plugin. The Concepts chapter and SQL Reference always bring up a hit and I always find what I'm looking for.

Many problems/arguments in the office have been solved via "Has ANYONE looked at the docs?" (which is often followed by, "Well, create a test case"

Tue Sep 05, 10:46:00 AM EDT  

Anonymous RobH said....

on a side note:

Part of the problem with oracle is the "hidden" things. I understand why they have them, but all the _parameters, and x$ views and system tables aren't well explained at all.

How/why did you learn about x$bh? It seems like a logical thing to want to know what, and how much is in cache.

Wed Sep 06, 08:40:00 AM EDT  

Blogger Thomas Kyte said....

I don't do "_" things
I don't do "x$" things

v$bh is there, documented and all...

Wed Sep 06, 11:52:00 AM EDT  

Anonymous RobH said....

I don't do "_" things
I don't do "x$" things

No, I agree, but why even have them (or hide them). It makes it more confusing to understand and leads to the whole "unlocking the secrets of oracle" book/website fiasco. I'm sure oracle has great reasons for them, but to someone new, it adds complexity, and at best you have to tell yourself to ignore it. The problem then raises itself while reading books and documentation (even yours, p144, and J Lewis references the x$bh view). You can't always use v$bh inter-changily (sp?, even a word) easily.

Also, for v$bh, searching the docs and looking at the database reference: This is an Oracle9i Real Application Clusters view. This view gives the status and number of pings for every buffer in the SGA.

I know it was used in the past for oracle pinging on old days of Parallel Server, but still, the documentation is unclear of what the view really is (to me), yet its used all over the place(or I've seen) on non-RAC to view buffer cache contents.

So, is it a RAC View, Buffer Cache contents, both? Sometimes, the documentation is difficult to 'understand'. It feels condradictory sometimes and that makes learning tough.

Wed Sep 06, 03:33:00 PM EDT  

Anonymous Anonymous said....

Like this quote

Fri Sep 08, 03:51:00 PM EDT  


<< Home