Re: Read the manual? What you talkin' bout Willis?

I recommend, and follow, these steps:

From http://docs.oracle.com

1. Read the Oracle Concepts manual

I read this cover to cover at least once every 2 years. Skim once every month or two. Each time I look at it, I learn something new - usually because my experience has increased and I see things from a different perspective.

2) Be aware of the contents of the Database Administrator's Guide.

To me this means skimming the document in it's entirety several times a year.

3) Be aware of the contents of the Application Developer's Guide - Fundamentals

To me this means reading the document in it's entirety at least once for each version.

4) Post a copy of the "List of Books" for each version in my office. Bookmark the lists in my browsers as well.

After steps 1-3 which tell me the basics, this tells me what is available to provide details.

5) Skim the Oracle docco, starting with the ones marked "Concepts" and "Fundamentals" and work toward the more detailed ones as time and interest permits.

6) When reviewing and old problem, or addressing a new problem, see if I can identify the most likely document source from the above. Verify.

7) Learn to use Oracle's docco search engine

8) Read at least 1 related book each month.

I budget 8 hours per week to learn about the products - part on company time, part on my own.

9) Build on the work of others.

My reading list starts with the recommendations by the Oak Table.

1. Challenge myself

I present something related to Oracle, Linux, Java or XML at least once every month. I like to see if I can develop a demo based on the questions asked in these forums. Many of these are flops and never get shown, but at least I learn from them.

B) Think [about ROI and failure paths]

I believe strongly that the major problem in our industry is that we (the developer, DBAs, designers, etc.) have let ourselves be pushed into a 'get it done fast, we need to keep the shareholders happy' mentality.

Unfortunately, the only ones who win in that are the shareholders. (The shareholders don't care about us - they are narcissists anyway.) If we rush, we end up delivering crap or prototypes, and get absolutely nothing in return. We don't even get job security, because we eventually end up losing our jobs when the company folds or lays us off.

Instead, I try to develop defensively by looking at the failure paths. That generally means taking on the bean counters by understanding business and developing TCO and ROI models to justify why the job should be done right.

C) Google.

I turn to my experience first, then the docco, then my library, then Google, finally the newsgroup.

D) Take time off

FGB Received on Fri Feb 25 2005 - 17:17:58 CST